“ Anxiety arises from not being able to see the whole picture. If you feel anxious but you are not sure why, try putting your things in order.” — M...
For further actions, you may consider blocking this person and/or reporting abuse
Thanks for great overview of these architecture patterns. I'd like to add one more thing to the whole picture: there is another architecture design pattern which fits the picture very well: Functional Core, Imperative Shell. It does not affect general picture drawn by you, just clarifies how to implement inner layers of the architecture in more convenient way.
Definitely I will take a look at this. Thanks, Sergiy! :)
Here are my considerations in regard to such a combination of architectures.
Another observation: in real applications there is often are issues caused by leaking abstractions. For example, in theory replacing one type of repository with another (for example, MySQL with NoSQL) should be easy. But implicit knowledge about particular DB type capabilities often leaks into the repository API and then up to outer layers in the form of ordering/pagination/aggregation/etc. As a consequence switching to another DB is possible but only if this is the same type of DB (i.e. relational, for example).
I agree. The main problem with software architecture (abstractions, patterns, even solid principles) is that most of the times some people understand them in a way that is not complete. They understand the main idea, but they don't know how to do it properly and what they get is a bad abstraction system, with huge coupling.
What you mentioned, I have seen a lot of that in .NET/C#. The most used ORM is Entity Framework, and in several cases, I saw like developers were using the database model as Entities in DDD. And you know, that is the beginning of the chaos where the ORM data model is coupled to the domain and also the Application Services are coupled to the Data Model... and the tech debt increases in every task creating a nice spaguetti code.
Hello, these are great articles. Many thanks. Can't wait for the next part with that API example. Also, you came in the right time because we are wondering with my colleague how to rebuild and restructure our old codebase. (You know all in one, or village design)
Nice article/Serie.
I've seen some other diagrams of Clean Architecture, where the repositories interfaces are located in the Application Layer and not in the Domain, as it is in your boilerplate. Things like IDbContext aren't more applied to a Database interface?
Cheers!
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!!
Hi, David. Awesome articles.
I didn't understand where Web APIs belongs to. It is infrastructure because it is framework dependent and it should call an regular API (non REST) on presenter layer?
Thank you
Hi David,
Nice article, for Mediator, does your Mediator as an Interface?
Hi!
To use the Mediator pattern in .NET for example, I have used external Nuget packages like Mediatr or FluentMediator so they provide me the needed contracts or interfaces that I need to implement with the different domain commands and event handlers.
Then you need to register them in your IoC container to get the benefits of DI wherever you need them.
Here you can find some samples: github.com/jbogard/MediatR/tree/ma...
github.com/ivanpaulovich/FluentMed...
I was pretty busy these past months, but I think it is a great topic to cover in an article :)
Thanks for reading!
Hello David, on dev.to you can use the series (Front Matter) keyword for easy navigation from part1 to last article :)
Oh that's great! Sure I will give it a try later on today once office job is done! Thanks Jeff :)
Hi David, Great serie/article, thank you to share knowledge with us, helps a lot full and brings me many ideas to try implement these approaches.
Regards.
Wellington