Nearly a year later, I must say I have to accept this not as an answer but as a lecture as if I took it in a class. Did a lot of research, made a lot of sample projects, watched a lot of videos and read quite a lot of articles. It all now makes sense and I can't believe how my mindset was before. Thank you very much for what you have tought me!

** Comment 4/4 - **I am not an experienced developer. The unknowns to approaching the problem - let alone identifying it - is a very steep journey for me. Guidance in starting at the right point is all I want. So, I'll now try to eliminate all the relational entities as repositories and seek ways of manipulating them through the main object they belong to.. E.g. Instead of having a repository for the ProductPackaging separately, I will do the basic CRUD through the main Product by doing Product.ProductPackaging = new ProductPackaging {...} within the ProductRepository am I right?

** Comment 3/4 - ** Until.... You identified my problem - The Foo Trap.. I am definitely in it. In my project, my "subdomains" are Store, Product and Customer. Remaining are sub classes such as StoreOpeningHour.cs, ProductPackagingOption.cs which 99% of the time can be etc... I ended up just like you described above. 99% of the time all the I am not moaning about spending time. I am trying to learn here but I also believe in spending time efficiently.

** Comment 2/4 - **The issue is whether implementing this sort of architecture (fully/partially) has a "VALUE" or not for a particular case/project. In my case, given the facts above, introducing a repository pattern is a burdon on me causing a lot of time consuming work and I was thinking to get my services layer couple with EF directly would be a better choice..

** Comment 1/4 - **As I read and watch more about the subject, I am quite close to coming to a conclusion that the matter is not the answer to the question but rather whether it is the right question to ask or not. I am a single dev working on simple to mid sized projects that are not for any customers but for my own use within my own businesses. I have and will always (until they are replaced by their own predecessors) use SQL server, EF

@RikD things are getting interesting now.. :) Then there is this

@FilipMilovanović thanks for the comment. So how can I implement this idea with a generic service? (if it is possible of course) He also registers services in the Startup.cs As you said, for most of the entities the generic repository is more than enough form me as the need for anything other than the basic CRUD will not be needed for ever. But I am quite new to the concept to figure out how to implement it to this code. Any ideas?

@EricKing thanks for the comment. I've come accross to one of your answers to a similar question and the accepted answer here. However it has been 8 years since that. Could you let me know if your answer is still valid for that question? If not could you answer the very same question in today's time?

some others suggest creating a seperate project for identity and referencing that project as well.. what do you think of that approach?