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

Highly recommended for software developers who want to improve code quality!

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 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.

I have read four books, dozens of articles, and have watched scores of videos by Uncle Bob. As always I found this one fascinating and well written. Bob has a flare for synthesizing very complex technical material from many sources, then boiling it down to easily and enjoyably absorbable explanations. He manages the magic of combining theoretically deep discussion with a very practical, even advice-like perspective. I'm so happy he's made himself the uncle of young programmers like me and invited us to squat on his lawn. My caveat is that, having gone through so much of Bob's previous material, there was unfortunately much here that was already familiar to me, including some sections that are taken almost verbatim from his previous writings. In itself this is no problem - had it been the first I ever read of the man I would be totally ecstatic about it, and it's reasonable of him to assume that most readers would not have followed him around the internets as assiduously as I have. But I was hoping to hear more about topics he only hinted at in his blog posts, e.g. the different kinds of architecture implied by different desired user experiences. I read him mention event-driven, request-based, and batch processing, and I was assuming he would elaborate on these ideas in this book, which he does not. There are many other details I wish he'd gone into or at least offered good follow-up reading on, such as presenters and the creation of use cases. Finally, he does not appear to provide the name of the stellar body on the cover, which is an unfortunate break with custom.

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.

This book is pure history, really enjoyable reading, the autor experience is priceless and the examples in every chapter gives you how the engineers work back in the day !!!!

I'd never picked up so much transformative material since I studied computer science. This book will change how you create your software and will push up the quality of .your output a couple orders of magnitude. I cannot understate how important a read this is, it's for sure an instant classic, on the same tier as The Mythical Man-Month, and your algorithms and data structures books. I think, though, that in contrast to those two other books, you get a lot more mileage out of this book if you've already shot yourself in the foot by having at least two or three fully done projects under your belt. As I read this books I nodded in agreement in pretty much all of its points because I can instantly remember the pain of not having designed systems this way in the past. As a new programmer I do not think I would have understood most of these points, especially if I were a new grad and had only worked in systems of couple hundred to one thousand lines of code. To me, this is a book to help you make the leap from an experienced software engineer to an expert software engineer and architect. This book has almost no code in it, so you certainly can read it as a newcomer to the field, but the lessons contained will not really sink in until you have a few battle scars in your skin, and you'd much rather not repeat past mistakes.

I started this book with high expectations as Clean Code was a wonderful book. Will Clear Architecture be like that? Unfortunately, no. This book is still worth reading for people interested in software design, I don't believe the impact and role of this book will be similar to the earlier Clean Code book. There is not that much news and most of the book seems to talk about the architecture of relatively small systems. The book has 6 parts, (1) Introduction, (2) Starting with the Bricks: Programming Paradigms, (3) Design Principles, (4) Component Principles, (5) Architecture, and (6) Details. The Introduction part clarifies the authors definition of architecture and design. In the second chapter, it looks at two 'values' of software, behavior and architecture. The author then claims that of these, the architecture provides the greater value. I felt this was a bit of a strange argument to make. Obviously a good clear design is important but there is nothing to be gained from stressing that one has a greater value than the other. The second part introduces three programming paradigms. I was surprised to see this in a book about architecture didn't mind as I do enjoy reading about programming paradigms. The author claims that there are three and there will never be more, which came a bit as a surprise as I was aware of more than 3 paradigms (and so is the wikipedia page on programming paradigms). The three paradigms covered in this book is structured, object-oriented, and functional. It describes these three from an interesting perspective, which is that each one adds a constraint. The third part is a summary of the SOLID principles which Robert Martin has covered many times in his earlier work. They are described a little bit differently as before. I am not a fan of the way the Single-Responsibility Principle is explained in this book -- "a module should be responsible for one, and only one, actor" and felt the example a bit strange. But all in all, the SOLID principles are useful principles to have in your toolbox. The fourth part introduces components and component principles. These have also been covered in the Agile Principles, Patterns, and Practices book from the same author. They are an interesting read but, over the years, I've not found them incredibly useful and practical. Part five, called architecture, is the majority of the book and is pretty good. In the first couple of chapters it introduces some basic concepts on how to think about software systems and how they can be decomposed differently. After this, one chapter introduces the "clean architecture" which is the standard architectural patterns that the author considers 'best.' A clean architecture separates entities (domain objects), use cases, controllers, and external interfaces. That definitively feels like a good idea for most software systems and the book does a good job in explaining why and how you can do that. Of this part, I particularly enjoyed the criticism of the micro-services hype that has been going for a while. Here the author is spot on. Part six is called details where the author covers things that he considers to not be part of the architecture but that should be hidden as details. Outside the book these are often discussed as important architectural decisions and the author wants to make a point that he does not agree with that. These are the choice of database or data storage, the web or choice of user interface, and the choice of application framework. The part wraps up with a case study and a chapter written by a guest author. Appendix A is still 50 pages of additional writing where the author summarizes his experience in working on different systems and what he has learned from which systems. Clean architecture was an interesting read. I liked the clean architecture pattern that the author presents and his explanation of it. That makes the book worth reading. Other parts I likes less and often felt the description was a bit over simplified. Four points stood out to me, (1) the assumption of code ownership, (2) the focus on up-front structure rather than gradual evolution, (3) the complexity suggested rather than going for simpler solutions and adding complexity when needed, and (4) the focus on relatively small systems. I could write a lot about these but I'll leave that for another time. I do want to focus a bit on the 4th point though. The examples throughout the book are from relatively small systems where I can easily see how the clean architecture patterns applies. For larger multi-technology systems, the book left me with many open questions. Anyways, all in all, this was a decent book. It wasn't wow and a lot was a repetition of earlier work (such as the Agile Principles, Patterns, and Practices book). I was doubting between 3 and 4 stars but decided to go with 3 because of the above points. A good read for people interested in design of software systems.

The book itself, a must have. I was disappointed to receive a used copy. I requested to replace it considering the price, but nothing happened.

Dobra zawartość, dobrze się czyta. Nic tylko polecać chcącym poszerzać swoją wiedzę.

This book is a real gem in the software architecture field. It discusses the basics and programming paradigms, then goes up a level and speaks about component cohesion, then component coupling, sketches up a general architecture model that relies on these principles, and then explains many different cases and patterns. Arguably one of the most valuable books I've ever read.

Martin follows a clean and practical approach in this book. He explains with great pedagogy key concept of the architecture. As any other book of practices, this is a merely guide or tool, so you should be careful and diligent evaluating your requirements to see if the advice given in the book applies to you.

A must-read if you care about the architecture of the software you are working on. You don't have to follow all the rules by the book, but the reflection about architecture is what matters.