Chapter 8: Conclusion and final words

I’ve spent a lot of time exploring these topics over the last months. I hacked in the subway every day and rack ones brain after kids where in bed. I’m quite happy with the result but I also see room for improvement here and there.

The nice thing about Clean Architecture (and others) is that they push you to do small separated peaces that do only one thing (separation of concerns) and to decouple thinks. Further more one does not only decouple but also organize them into layers the way that inner layers only know the general interface but not the concrete implementation.

This results in excellent test-ability and one can easily replace an implementation without changing the overall concept.

The nice thing about Domain Driven Design is that the business logic and flows are put into the center and that one builds a “domain model” out of it in a nice object-oriented fashion. We no longer have dumb objects that gets manipulated by services all over which are more procedural programming like.

The overall architecture I came up with in the sample application uses the same building blocks and clearly defined flows for all use-cases. I don’t have these strange service-dependencies all over.

I am also forced to think more about the business needs of a use-case. For example I need a use-case to start with. I need to think about how things are named in business terms (entities, entity-methods). This builds the ubiquitous between the business and the techs.

On the other hand this kind of architecture leads in more lines of code. But I think its worth it!

… at least if the application not only a trivial CRUD app but has business flows / logic.

Thanks for reading. Cheers!