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

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 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'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 was hesitant to buy this book because Uncle Bob is known in software community as a fundamentalist zealot for his views on software design and testing (TDD). This book starts out with similar hard views and he claims that a useless program that is easy to maintain is better than a useful program that is impossible to maintain. I have seen a lot of bad design and implementations in my twenty plus years of experience as a software architect/engineer but nothing is impossible. As a profession software engineer, you are expected to support business and have to work with various constraints in your organization. These constraints vary based on the context and unique environment, which is why I prefer Kent Beck’s advice of making it work, making it right (refactoring) and making it fast.Most of first one third of the book provides overview of programming paradigms such as structured design, object oriented, and functional decomposition. He then covers SOLID principles that he is best known for, i.e. single responsibility principle (SRP), open-close principle, liskov substitution principle, interface separation principle (ISP) and dependency inversion principle. In my opinion, these principles can be boiled down to interface/implementation separation and using composition over inheritance (concrete). He then applies these principles to components design such as reuse/release equivalence principle for releasing same component together, common closure principle similar to SRP and common reuse principle for using interfaces similar to ISP. Uncle Bob provides useful advice for using acyclic dependency principle for dependencies between components and ensuring that abstract/interfaces are used in stable components and volatile components (concrete implementation) should depend on stable components and not otherwise.The last one quarter of the book finally starts with explanation on clean architecture that uses hexagonal architecture. He states that architecture should be independent of frameworks, UI and database. His definition of architecture only focuses on component design and communication but I use architecture as any design decision that is costly to change and often that include choice of databases, frameworks and UI. He uses layers and boundaries to divide system into various components and recommends use of entities for business policies, using techniques such as humble object pattern for testing hard to test components. In final chapters, he proposed designing components based on use cases instead of horizontal, which has worked better in my experience when working on a large system.In the end, this book has plenty of nuggets on design of components but take this advice with a grain of salt. Uncle Bob’s militant views on clean design, test driven development and his abhorrence for tools is not very pragmatic. For example, he doesn’t mention technical debt, refactoring or dealing with legacy systems. Though, he pays attention to maintainability but he ignores most of other non functional requirements such as scalability, availability, reliability and ignores emphasis on developer productivity. In my experience, software design and development should start with the business requirements, constraints and organization structure. You may be working in a startup that needs to prove an idea with minimal effort or you may be working on designing a service with a large number of users. Similarly, you may be working with a small team or on a large project that needs to interact with a number of teams where you may need to apply Conway’s law to design the system. In real world, you face these choices instead of writing perfect components with 100% test coverage, which may be maintainable but not useful to anyone and thus killing your company and leaving you without work.

My background is Java backend and building microservices by Spring Boot, Framework does not solve all problems. This book helped a lot in how to write good code, in the high flexibility and “stability” perspective. It’s also stunning to see the evolution of architecture from 1970s, which needed people to write programs in assembly language!

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.

The author can be too chatty sometimes. His opinionated "writing" style can cloud the essence that he is trying to get across. Having said that... I was happily surprised that most of the stuff he taught. It seems like an old guy wrote the book and wanted to include the foundational elements of how to produce decent architecture in general. Luckily I must have had good professors because I found it to be a strong overlap with what I had found through my years of research anyway.The nice part of this book is that everything is in one book and is a quick read (2 days here). If you're rusty or lets face it, were never clear on what dependency inversion is or how to do it -- this book should help. I was in that boat, having heard of it for a long time. I was actually already practicing it without knowing that I was. This book helped me discover that for myself.I do like how he talks about what details are in a system.To put it concisely:What is the responsibility of the architect(s) ? to keep the software soft (by managing the dependencies and remaining concerned with the interfaces)

This is a phenomenal book about good practices of software architecture in general, on how the SOLID principles, programming paradigms translates into architecture. It also makes a phenomenal explanation about components, how these can be (either stable or unstable) and when you want a component to be like these.However, this is a book full of knowledge, theory and there is nothing practical (besides some basic diagrams), it's not like if the book got some practical project that gets with code, you barely see some. But I think that's okay because when you first read about Clean Architecture on the Internet, what you first find (or I least I did), its projects using CQRS and Mediator patterns just because.This books gets so much into details, and it advises you on how to make good architecture that will make a software piece last over years. It never mentions "Mediator", it does mentions CQRS but doesn't do any emphasis, because that's not what this book is about.This book is basically a bunch (a lot), of excellent advises, on how to design good architecture, and I loved it, I did learn a lot of theory and also I had a lot of fun because this guy, uncle bob, can definitely write.

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.

Great fit

His books are always easily digestible and full of useful advice. Unlike many of his authoring peers from the last couple decades, his work remains relevant.