Book Review

Book Review: Clean Architecture

You probably already know that I am a fan of Clean Code – all the way to the point of giving training courses. So I couldn’t miss Robert Martin’s (aka Uncle Bob’s) third book Clean Architecture, which promises to extend the reach of the first two books into the realm of software architecture.


The book continues from the previous two into the realm of architecture. After an inital part explaining the need for a good, clean architecture, the book is split into the following parts:

  • Paradigms
  • Design Principles
  • Component Principles
  • Architecture
  • Details


In this part, Uncle Bob explains the different programming paradigms. Well, at least he explains the most well-known ones: structural, object-oriented and functional programming. He conveniently tries to hide the remaining ones from his readers, even claiming that “there are unlikely to be any others”. Not that we need to wait for the future for this, but at least logic programming is widely accepted as another one and then we’re not even touching on those yet, where one may indeed start questioning whether they are separate paradigms, like aspect-orientation or constraint programming.

Design Principles

In the first part, the author makes clear that he considers design and architecture to be the same. Which is fine by me, but kind of makes it pointless to have design principles followed by the architecture part later-on. Anyways, this section was just a way to fill the book, as it reiterates the content from his Clean Code book. The principles are simply the five well-known SOLID principles.

Component Principles

Components are an integral part of architectures but this section is not very informative either. It basically talks about the problem of finding the right balance between coupling and cohesion. Something like the Stable Dependencies Principle may be mentioned here as the honorable exception.


The book basically starts here. If you already have some software design and architecture background you may as well start reading here and save yourself some time. Starting with this part, every chapter becomes a sort of principle. I’m not going into any details here, but for your and my convenience, here’s a complete list of the chapters:

  • What is Architecture?
  • Independence
  • Boundaries: Drawing Lines
  • Boundary Anatomy
  • Policy and Level
  • Business Rules
  • Screaming Architecture
  • The Clean Architecture
  • Presenters and Humble Objects
  • Partial Boundaries
  • Layers and Boundaries
  • The Main Component
  • Services: Great and Small
  • The Test Boundary
  • Clean Embedded Architecture

Each of these describe in more detail certain aspects, we have to take care of as software architects. Some of these are particularly interesting for the scope of this review:

  • The Clean Architecture – presents Robert Martin’s idea of how an architecture should look like. If you know the Onion Architecture, you already know Clean Architecture. It’s just that the domain-driven design folks use a more domain-focused naming scheme.
  • The Test Boundary – this and the last chapter are probably the best ones. I have seen time and again, that the architectural planning did not account for the test strategy. This chapter is a testament to the shift-left movement for tests and teams who started to bring testers in earlier probably already encountered that this should also result in the architectural decisions taking tests into account as well.
  • Clean Embedded Architecture – having met a lot of resistance in my training course from developers in the embedded domain, this chapter was very interesting to me. I never quite got into the embedded world and never really understood why they are lacking behind over a decade in their software development. There was no actual reason I could see, other than the embedded developers simply not being as focused or driven in improving their development experience. I still don’t understand jack about embedded software, but at least now I can point people to this chapter, where Uncle Bob basically explains, that explicitly splitting software, firmware and hardware allows you to reap the Clean Code benefits at least for the software layer.


This final part contains a few chapters that didn’t quite fit in with the rest, or are simply explaining that something does not occur more prominently for a reason. For example, databases and the web are covered here, and why they do not actually matter with regards to software architecture. The final chapter in this section was quite an interesting read and surprisingly well-written and not something to be offended with every other sentence.  It is really just about the “public” keyword in java. For over a dozen pages with fancy colored diagrams. It’s exactly this sort of attendance to detail that is at the core of Clean Code to me. Strangely enough, this chapter is a guest chapter written by Simon Brown, the inventor of the C4 architecture pattern. For some reason, he deserved a guest chapter, but Robert Martin did not deem it appropriate to include his C4 pattern among the existing architecture patterns throughout the rest of the book. Suits the style of the author (see below).

Target Audience

Apart from the obvious software architects, the book continues Uncle Bob’s series about Clean Code, hence, readers of the first two books may be interested as well.


The book is quite typical of Robert Martin’s style. From my discussion with colleagues this style seems to split the audience into readers who can just accept it as it is and readers, like myself, who feel offended every other page. His writing is very direct and his personal opinion isn’t just borderline arrogant – it goes well beyond that point. If you are looking for an objective fact-based book you should rather stay away from this one. If you’re used to Uncle Bob’s style and it doesn’t bother you, then make up your mind based on the remaining points.

Personally, I was close to throwing the book at the next wall at times. Gladly, I remembered that I’m holding a kindle in my hands, which was not responsible for its content and could still serve a better purpose when not thrown at the wall. You may ask why? Well, one instance was when the author proudly explained the reasoning for writing his own web server – mainly, because it avoids lock-in and allows a quick change afterwards. Having added jetty webservers with a handful lines of code myself, I highly doubt that a replacement is much quicker with your own. Let alone the time difference between downloading and calling an existing code, compared to rolling your own. Yes, it may not be much, but wasting a week or just a few days for something that takes other projects less than an hour, is just not going to cut it in my world. There are other such instances, f.ex. when he explains why the whole microservice movement is based on a fallacy. Again, I’m not very deep into that, but I’ve heard enough to know that microservices can fulfill on their promises, and that you could do it wrong as with any other tool.


After reading the book, I was disappointed. The first two books were fantastic – despite the style issues. This one feels like Robert Martin has burned his fuel and just rehashes old ideas. The arrogant writing style and the sheer number of statements that I have to vehemently object to, almost made me put the book away – several times. Yes, I’m giving courses on Clean Code and yes, the book has been out for a while now already, but yes, it was a tough read that I had to force myself through. If it weren’t for that general Clean Code context, I’d probably never finished it.

That’s just my personal impression though, but I’m afraid I also cannot recommend it to others. As an experienced developer, I just find too many of his statements questionable. Don’t get me wrong – he may be right and I may be wrong, but given that I’m supposed to just believe his words, since he left out the rationale on how he came to these conclusions, I’m not feeling good about a recommendation. Heck, in a few instances where he actually tried to provide a logical inference for his reasoning, it is not even sound (sound meaning correct – for those of you who don’t have a PhD related to logic).

In terms of content, he contrasts his proposed clean architecture with traditional architectures, but comfortably leaves out other modern architecture concepts (like C4, hexagonal, or onion architectures). The book did not convince me that Clean Architecture would be better than any of those. Ultimately, in case I extend my course with an extra day about architecture, I will certainly not base it on this book. I may take an idea or two from it, but that’ll be it. Others have more interesting things to say about software architecture.