Under my understanding, that approach is not correct. At the end, you need one repository by aggregate root, so if you are defining the interfaces of those repositories outside the Domain layer you are breaking the dependency rule because you are using domain concepts outside the layer which is responsible for those things.
Also Application layer should be for everything regarding application logic, like use cases logic and things like Service pattern, strategy pattern to handle lots of different choices for example, etc.
I think there are a lot of not great implementations of Clean Architecture out there when using Entity Framework.
I will try to go on with my next article from a more on hands POV these next weeks :)
Thanks for reading!!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi!
Under my understanding, that approach is not correct. At the end, you need one repository by aggregate root, so if you are defining the interfaces of those repositories outside the Domain layer you are breaking the dependency rule because you are using domain concepts outside the layer which is responsible for those things.
Also Application layer should be for everything regarding application logic, like use cases logic and things like Service pattern, strategy pattern to handle lots of different choices for example, etc.
I think there are a lot of not great implementations of Clean Architecture out there when using Entity Framework.
I will try to go on with my next article from a more on hands POV these next weeks :)
Thanks for reading!!