As a huge fan of the Robert C. Martin book series I preordered his new book Clean Architecture. Finally, it has arrived!
The book starts off by outlining the difference between behavior and structure of software projects. Using Eisenhower’s urgency/importance-matrix we learn that architecture is very important but never really urgent, which is why it is often neglected. Developers and especially architects must enter a struggle with the other stakeholders of the software which value immediate behavioral features more than architectural work. In the end it is our responsibility as developers to do the right amount of architectural work.
As a man with lots of experience, Uncle Bob gives us a history lesson about programming paradigms and what kind of improvements they are bringing to the table. The SOLID design principles are once more presented – this time though through the eyes of architecture. They are followed by a definition for components and three architectural component design patterns: the reuse equivalence principle (REP, the granule of reuse is the granule of release), the common closure principle (CCP, gather classes into components which change for the same reasons at the same times) and the common reuse principle (CRP, don’t force users of a component to depend on things they don’t use). All three patterns are building up tension between each other and it is the architect’s job to trade them off – and to reevaluate the trade-offs at times, as the focus might need to change.
Next up is the number one lesson of the book: dependencies must always run from the specific and infrastructural code to the more general code up to the business rules, the domain so to say, which should not have any dependencies at all. Also dependencies should go from less stable components to more stable ones which contain the abstractions or interfaces. Uncle Bob is a huge fan of plugin architectures which follow the open/closed principle: you can plugin different specific implementations to general interfaces at any time and until late in the project. We also learn about the SAP, the stable abstraction principle, and even about a metric to calculate which components should be put into consideration for re-architecturing.
The book then turns into a list of good advice for architects. Architecture should simplify development, deployment, operation and maintenance. It should keep options open as long as possible, it should allow components to become independent if need be. From screaming architecture over how to draw boundaries and how strong boundaries have to be (from different namespaces to service oriented architecture and micro services), test architecture and even a chapter about architecture for embedded software systems.
Some indoctrination at the end: Database, the Web, and any frameworks are details and must live on the outer rings of our architecture. They are specific and they are infrastructure. The domain should be kept clean from such details.
The last chapter in the book is by another of my favorites: Simon Brown. He presents some well-known architectures (horizional and vertical layering, ports & adapters, packaging by component) and tells us about their differences.