Clean Architecture: A Craftsman's Guide to Software Structure and Design (Robert C. Martin Series) 1st Edition

No doubt that Robert C. Martin is one of the most influential author and software development theorist of our times. The already standard SOLID principles had been with us for decades, serving software discipline with full success. The Clean Series is a set of books full of advises, thoughts, ideas, rationales and principles with the same impact. If you know his videos and lectures, probably this book will see familiar and many of the topics discussed repetitive. But the book has the value to reunite and review his software development discipline philosophy in a concise and complete harmonious set of essays.The main idea is to avoid dependency applying the Dependency Rule at all levels, classes and components. The Dependency Inversion graph, where high-level functions calling middle-level functions through an interface that the middle-interface implements, is a medular software construction that should be applied as an obsessive pattern. It guarantees independence, reusable, clean architecture. This book explains how and why for this.The result is the idea of Plugin architecture where the core of the system, the set of functionality that implements the use cases and business rules (interactors (R. C. Martin)/controls (I. Jacobson)/controllers (C. Larman) should be the center at which all other parts (IO components, details) will point via abstractions (interfaces or abstract classes).I have been practicing clean architecture ideas for many years (and before Martin coined the term) following Martin guidance a principles. Its product is natural, simple, robust, structured, reusable and beautiful to work.Paradoxically, the last chapter about packaging components--written by S. Brown--seems a contradiction to the whole book ideas and Brown somehow point to that ("My definition of a component is slightly different..."). In that chapter, Brown explains several alternatives for software architecture organization with a marked inclination for a monolithic package that represents the services of the system (and repository interaction) and another that represents the controllers. The reasons of that resultant recommendation (a junior undisciplined programmer that don't follow the cleanliness of the architecture, etc.) are really weak and out of the architect control. His recommendation violates almost all components principles explained by Martin (REP, CCP, CRP, etc.)I love this book and totally recommend the book for all fans of good, clean architecture.

I liked this book less than the Clean Code, but it was a better read for me than the Clean Coder. I've found a distillation of this book in article from Robert Martin, which he wrote in 2012 while working at 8th Light (I cannot paste a link in here). The book is partially a very detailed description of the ideas from the article and what is behind them.The book starts with 3 myths we developers live in:1. Myth: We just need to get to market first and we clean it up later.2. Myth: Messy code makes us faster today and slows us later. Myth: We can switch mode from making messes to cleaning messes. (making messes is always slower, even in very short term as shown in example of a simple kata in the book)3. Myth: Starting from scratch is a solution.There is a well written history lesson in the next part. Uncle Bob presents Structured Programming, OOP and Functional Programming and says there is nothing else (programming paradigm-wise) to be invented. Part 3 is about SOLID principles from architecture point of view and part 4 are his Component Principles about component cohesion and coupling from his Agile Software Development book.Part 5 is about Architecture and was the most interesting to read. Most memorable chapters for me were the Screaming Architecture and the Clean Architecture. Both of them are not new, you could have seen them in his videos or the article from 8thlight. The point of Screaming Architecture is that when a new developer joins a health-care project, he should be able to immediately tell "this is a health-care project" just from the project structure. Another topic which was part of multiple chapters, are micro-services. I felt that Robert Martin is not very fond of starting with them. He says services are little more than expensive function calls and as a communication mechanism between the project boundaries (i.e. a detail), they are a decision which should be deffered as far as possible.Part 6, the Details, are a detailed explanations of his article Clean Architecture from 2012. There is a little gem in there, the Missing Chapter 34 written by Simon Brown. I liked his explanation of 4 different kinds of packaging classes together to form components.

I found a lot of the explanations to be very clear and thought provoking.However, there is little practical advice on making trade-offs, supporting operational requirements, etc. This is a book about structuring software components. The subtitle says as much, so you shouldn't expect a complete guide on application, system or enterprise architecture. In fact the author seems to misunderstand the meaning of "service architecture".I think, overall, this is a very limited, if important, perspective on software architecture.Still, it's a relatively light read with interesting insights.