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

It's a great book

Great book!

It looks like the book was a victim of a razor blade. I'm going to tape it and carry on since I love my books pretty hard anyway, but I'm bummed it has sliced pages. What matters is the information.

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