I'm thinking about adopting the clean architecture.
The main thing in this architecture, as I understand it, is the dependency flow from top to bottom. So the first thing that I asked myself is: what would be the cost to change the bottom layers (i.e Entities)? This layer will have lots of dependencies, and by changing it I will have to change all the layers up to the top.
Am I right or am I missing something?
You are right!
If you change any of the "business objects", you are in for a lot of secondary changes throughout the code, most probably in different packages as well.
In this article I do exactly this experiment with Uncle Bob's own Clean Architecture / Clean Code case study github project: https://javadevguy.wordpress.com/2017/11/15/screaming-architect/
Result: In this extremely trivial project, I had to change 5 classes (50% of application) to add a single independent data field. This would get much worse (even potentially exponentially) in a bigger application.
Here is another article analyzing, among other things, this seemingly unmaintainable nature of this architecture style: https://javadevguy.wordpress.com/2017/07/27/a-detailed-analysis-of-the-clean-architecture-from-an-object-oriented-perspective/
Conclusion: The "Clean Architecture" may fit projects in which the "business" part never or rarely changes while technologies change a lot. It is optimized for changing technology stacks. I'm unsure what project want that instead of business features.
Think in the clean architecture neither of layers nor of positions like top or bottom. It is fundamental to think of (maybe) rings or shells that can be used by outer rings and protect inner rings.
The most inner ring should always be your domain and therefore is not able to have dependencies to any other ring surrounding it. In rough terms this means, your domain is free of technical or application specific aspects. Hence your entities are done right, if they only depend on other components in your domain.
You will maybe ask yourself now, how on earth do I communicate with infrastructure, let's say a database, if I cannot have a dependency on that. And here, as the bard tells, lies the rub. You simply define an interface in your domain that describes a concept of an behaviour that you need. In this case how to store your entity. But you do not have a concrete implementation in your domain. And you don't need it, because interfaces are abstractions for general concepts. How exactly your entity is stored, is not a concern of your domain.
The implementation lies in an outer ring. Mostly in the outest ring, sometimes called infrastructure ring.
With your main method (the application) you then can create a suitable implementation and give it to your domain. This is often done by some dependency injection mechanism.
So in the end there is nothing mystical. Your domain defines what it needs from outer layers in a business like way and your outer rings implement and wire them.
For further reading I would recommend Uncle Bob Martin's article on the clean architecture on one of the many sites which have published it:
