Here are the assumptions that I have gathered via extensive research:
- “Domain models are separate to persistence entities.”
- “Repository Pattern’s best use-case is on the command (write operation) side of things as it allows you to load an aggregate as a whole.”
- “For queries (read operations) there is not much benefit and may possibly be counter-intuitive to add an abstraction over Efcore (such as with the Repository pattern).”
So now I’m left with the Core layer having domain models, the infrastructure layer with persistence entities and the application layer with Data transfer objects that map persistence entities and domain models to the presentation layer.
This is all made sense to me until I realised that in order for my application layer queries to use the dbContext, I needed a dependency on the Infrastructure layer. However, the infrastructure layer has a dependency on the app layer for things like Auth, Logging, ObjectStorage, etc. Leading to a circular dependency error.
I can’t define an “IAppDbContext” interface in the app layer as the app layer does not know about the persistence entities defined in the Infrastructure layer.
Curious to know what the solution to this might be?
The solutions I thought about are:
- Define a service per query in the application layer and implement it in the infra layer. But as you can imagine, this might be very inconvenient.
- Split infrastructure layer into two layers: infrastructure & persistence layer and allowing application to depend on persistence, clearing the circular dependency error but it feels like a hack.
I obviously understand that I should sometimes “break the rules” as certain things work better in theory than in practice, but the purpose of this question is to explore the solutions others might be using.