Book Review: Clean Architecture by Robert C. Martin
Book Review: Clean Architecture by Robert C. Martin
Uncle Bob is back! See how (or if) his latest book, Clean Architecture, will improve your architecture, design principles, and component design.
Join the DZone community and get the full member experience.Join For Free
Atomist automates your software deliver experience. It's how modern teams deliver modern software.
Uncle Bob is back! His newest book, Clean Architecture, was released about a month ago, and it’s meant to take your software engineering skills to an even higher level. Leaving all the low-level details far behind, the newest book puts maximum focus on the fine art of software architecture and attempts to lay out principles for creating successful, long-lasting projects in any kind of environment, at any point in time (yep, really!).
The book begins with a gentle introduction to the topic of architecture. Instead of the usual storm of buzzwords present in software architecture texts, Uncle Bob lays out a pragmatic, not-so-sexy goal:
“The goal of software architecture is to minimize the human resources required to build and maintain the required system.”
If you’ve read some of Martin’s previous texts, you won’t be surprised that the way to reach the goal is by keeping the codebase clean, only this time, we’re talking in terms of software architecture.
This, obviously, can set us at odds with those who want the software to earn money “right here, right now.” Here comes the reality of being a software architect: It’s a struggle!
Starting With the Bricks
The next part of the book touches on the topic of programming paradigms and their supposed evolution. After all, how can we talk about any kinds of high-level rules or principles in such a fast-evolving industry as software engineering?
The perspective that Uncle Bob presents is that the area of software engineering has not evolved that much at all over the last 70 years. Yes, we’ve got faster computers, more tools, new languages etc., but the core ideas remain the same. Any major “evolution” at the paradigm level can be presented as a constraint imposed on the preceding paradigm, so we’re actually dealing with less burden than our predecessors.
“Software — the stuff of computer programs — is composed of sequence, selection, iteration, and indirection. Nothing more. Nothing less.”
In the third part of the book, Martin invites us to take a deeper look into the SOLID principles. Instead of treating them as a bunch of class-level design tips, he goes on to extract the general wisdom that they carry around and explains how to apply it to software architecture.
The Single Responsibility Principle tells us to look at the different axis of change in the codebase so that a single piece of code is responsible for fulfilling the needs of a single actor.
The Open/Closed Principle helps us in creating a hierarchy of components in which lower-level components become plugins to the high-level policies.
Liskov’s Substitution Principle once again warns us of the consequences of partial module substitutability.
The Interface Segregation Principle transforms into a rule of not depending on things that we don’t use, not just on code “interface” level.
And finally, the dependency inversion principle becomes the dependency rule, which is the backbone of the whole Clean Architecture concept.
Having moved away from the class-level design and principles, we need a more suitable building block for the needs of software architecture. Against the current trend of micro-containero-distributo-somethings, Uncle Bob calls these simply components, defined simply as “units of deployment”.
The important part of components being effectively units of deployment is that we need to take extra care when deciding what does and what does not go inside one. The cohesion and coupling are no longer about “doing one thing” or “mixing things together.” There’s a tension between different kinds of benefits achieved by different kinds of separation.
Granularity of releases, code reuse, code stability, and abstractness and others are the main topic of this part, alongside with the rules that help us get the most out of them: Component Cohesion and Coupling Principles.
About halfway through the book, we finally arrive at the architecture-architecture part. From this point until the very end of the book, it’s almost all about two complementary topics: high-level policy vs. low-level detail and drawing boundaries.
If you’ve read anything about Clean Architecture before, there won’t be any surprises here. Enterprise business rules should not depend on the user’s use cases. The use cases should not depend on the UI, databases, and such. Whatever you do, follow the dependency rule by introducing boundaries between different kinds of building blocks.
Alongside the Clean Architecture concept itself, this part covers, in detail, a variety of topics: how to draw boundaries, the different ways of decoupling and enforcing boundaries, the relationship between layers, boundaries, tests, and so on, so forth.
This is the "meatiest" and most interesting part of the book, in my opinion, so I won’t offer more spoilers here. Go read the book, if you’re interested!
The last part looks a bit like a mix of things that didn’t fit into the previous parts of the book. And so we get a few more chapters about databases, web, and frameworks being low-level details (if you weren’t already converted at that point), a very short case study, and a guest chapter from Simon Brown.
So far, I've done my best to give you an objective description of what’s covered in the book and which thought directions are taken here and there. This was to spark your interest and level your expectations if you haven’t read the book yet. Now I’ll give you a bunch of fully subjective thoughts, which you are fully welcome to ignore or disagree with.
I dislike the book.
I hate to say it, but I was really disappointed when I finished reading. Don’t get me wrong. I had really high hopes for the book. I pre-ordered it the moment I first saw it available on Amazon and then read it on Safari because I didn’t want to wait for the physical copy to arrive. So my opinion doesn't come from any kind of general negative bias toward Uncle Bob or the topic Clean Architecture.
My first issue with the book is that it does not contain much more than you can find in other Uncle Bob’s teachings, like articles or videos. While the form a book is certainly a good way to organize information together and present it as a cohesive whole, the lack of novelty is somewhat disappointing for a long-term Uncle Bob fan.
The second issue, a bit connected with the first one, is that, in my opinion, it contains an awful lot of unnecessary noise. The whole walk through the paradigms and reiterating SOLID principles for the millionth time didn’t seem like a necessity for me. If there was a limited number of pages for the book, these chapters would be the one to throw away for me.
The third, and probably biggest, issue that I have is that the book feels very disconnected from a day-to-day reality of a software developer. Yes, it tells you that you should keep databases, frameworks, and others at arm's length. Yes, it tells you what kinds of levels can you see in your code and how the dependency rule works between them. But there’s close to none information about the “how” of that idea. And in my experience, the how of Clean Architecture is the hard part for aspiring clean coders. What we get here is a super-small, very basic case study that I found more confusing than useful.
Somehow continuing the topic of disconnection, the book also makes close to no reference to other trending ideas in software development like DDD, event sourcing, microservices, etc. Yes, the latter two are mentioned in a few sentences, but that’s far from helping people to map ideas to each other and help them get most of everything together. It feels like everything that “counts” is that the book's contents make sense together. The rest of the world is not important.
Now, that I’ve laid out both the objective and subjective things about the book, it’s your turn to decide whether to invest your time and read it. My suggestion is that people who haven’t read or watched a lot of Uncle Bob should definitely give it a read. You will find a good, cohesive way to think about software development. On the other hand, if you’re a long-time Uncle Bob fan (and somehow haven’t read it by now?!), you can put it further down your reading list. There’s nothing there that you must read right here, right now.
Opinions expressed by DZone contributors are their own.