Clean Architecture

Robert C. Martin Series

by Robert C. Martin

Building upon the success of best-sellers The Clean Coder and Clean Code, legendary software craftsman Robert C. "Uncle Bob" Martin shows how to bring greater professionalism and discipline to application architecture and design.

As with his other books, Martin's Clean Architecture doesn't merely present multiple choices and options, and say "use your best judgment": it tells you what choices to make, and why those choices are critical to your success. Martin offers direct, no-nonsense answers to key architecture and design questions like:

What are the best high level structures for different kinds of applications, including web, database, thick-client, console, and embedded apps?

What are the core principles of software architecture?

What is the role of the architect, and what is he/she really trying to achieve?

What are the core principles of software design?

How do designs and architectures go wrong, and what can you do about it?

What are the disciplines and practices of professional architects and designers?

Clean Architecture is essential reading for every software architect, systems analyst, system designer, and software manager — and for any programmer who aspires to these roles or is impacted by their work.

Genres: Programming, Technology, Computer Science, Software, Technical, Nonfiction, Coding

432 pages, Paperback

First published September 1, 2017

About the author

Robert Cecil Martin, commonly called Uncle Bob, is a software engineer, advocate of Agile development methods, and President of Object Mentor Inc. Martin and his team of software consultants use Object-Oriented Design, Patterns, UML, Agile Methodologies, and eXtreme Programming with worldwide clients.

He was Editor in Chief of the C++ Report from 1996 to 1999. He is a featured speaker at international conferences and trade shows.

Reviews

[Rod Hilton · Rating 4 out of 5]

I really liked this book but also was a bit disappointed by it. I'm a huge fan of Robert Martin's work, I've read his previous books and I love Clean Code and The Clean Coder. Based on the title and artwork I had kind of assumed that this was just the next step of the Clean Trilogy, this time focusing on architectural concerns.

It is kind of that, but it's mostly not quite that. Really, this book is a lot of background information to understand the "meat" of the book, and the meat of the book is Martin presenting his Clean Architecture pattern, which he proposed in 2012 and has been presenting and training a lot on: https://8thlight.com/blog/uncle-bob/2...

In that way, this book feels much more specific than Clean Code or The Clean Coder. While those two books are general advice for software professionals, this comes off more as an extended design pattern book that only covers one singular pattern. It's presented as The Only Right Way, and while I personally agree with Martin's perspective and his loathing for framework-heavy architectures, it was a bit disappointing that the book was mostly a very deep dive on a blog post from five years ago.

The "buildup" stuff is actually more interesting. It's about applying SOLID principles to architecture and I really enjoyed this section of the book, I felt like I finally grokked dependency inversion at a component level, and there's a lot to apply to architectural problems I face. That section of the book feels very general, though like most of Martin's work it's yet another rehash of SOLID and talking about FitNesse, two things he's gotten a stunning amount of mileage out of to a point where you kind of wonder if he's ever done anything else (he has, but boy does he return to these wells a lot).

In a way this is two shorter books smashed together. One is Clean Architecture, a book about building clean architecture using SOLID principles (and a few new ones). The other is a book about the Clean Architecture Pattern, a particular way to architect systems that shares a lot with Allistair Cockburn's Hexagonal Architecture pattern. These two concepts use the exact same name to, I think, intentionally get readers to conflate the two concepts as one and come away feeling like Martin's proposal is the only possible way to architect a system in a way that is clean. But one of these things is "clean architecture" and the other is "Clean Architecture", and it's often hard to see what is what. This is by design, I think.

In any case, the book is really good and I got a lot of out of it, though it wasn't what I was expecting really. The first half (or so) of the book feels like 80% rehash of stuff I've seen from Martin before, with 20% extremely good and useful new stuff. Then the second half of the book is a completely different topic presented as the same topic, which I enjoyed but I can see a lot of readers being turned off by. I still would recommend the book and I think it's worth reading for anyone who feels like "architecture" is part of their job.

[Eduards Sizovs · Rating 2 out of 5]

This is the first book of Uncle Bob that I didn't like – it's shallow, impractical, and full of stories from forgotten 90's. A significant part of the book (explanation of SOLID principles) has been copied (with few alternations) from "Agile PPP" book, which is, in my opinion, a much more thorough book.

To understand modularity patterns mentioned in this book, I suggest taking alternative path – reading "Java Application Architecture" by Kirk Knoernschild.

In addition to modularity and SOLID, the book tries to explain Hexagonal Architecture (a-ka Clean Architecture). Just Google it to grasp the idea and then read "Java Application Architecture".

The ideas mentioned in the book has practical application and are beneficial in some contexts. The problem is that the context is not set, and drawbacks were not properly examined. The book also lacks practical examples (the case study takes only 2 pages).

There a chapter that I like, though – it's a chapter written by Simon Brown (on packaging). In order to understand the idea, you can read Simon's blog post "An architecturally-evident coding style". Also, Simon wrote a great book – "Software Architecture for Developers".

[Tim · Rating 1 out of 5]

Such a sad and useless book. Let me save you time and money by summarizing the entire book in one deceitful sentence: "Use interfaces to hide implementation details." Done. Now you can go spend your $30 on something better. Like beer.

Of course the best part of it all is that now there is an army of bro-coders out there thinking that they know what's up, so every single code package they check in has a useless interface per every "implementation" class.

Here is a life pro-tip: if you ever stumble upon two files, one of them being an interface named, say, OrderService and another an implementation of that interface ending with -Impl, like OrderServiceImpl, please do everyone a favor and just merge the two. The sole fact that someone had to add -Impl to the class name means that there will never be a second implementation, so the interface they defined is useless and needs to be obliterated into the void. It's just garbage code that clutters the project structure. Maybe, just maybe, if we all follow that rule then the common sense will eventually prevail. Until then, God help us all.

[Sebastian Gebski · Rating 4 out of 5]

Some key remarks I have:
1. Even if it may look (at some point) deceptively simple, ... it isn't. In fact, the most valuable lessons will be truly comprehensible (& clear) only for people with certain level of experience.
2. This book doesn't try to cover anything in particular in the end-to-end way, it's more about certain aspects of software architecture Uncle Bob finds most important (e.g. SOLID principles, boundaries, proper approach to composition, etc.). Needless to say - these are universal & technology-agnostic (which is good), but they are most applicable to typical OO languages & platforms.
3. Appendix (that takes ~20%-25% of the book) is quite personal, quite impressive, but ... not really entertaining or educative. But well, it's Uncle Bob, so such things can be forgiven ;)

Is it a good, valuable book for an aspiring or even experienced architect? I think so - I like its focus on principles instead of patterns & I personally think this is something we truly need to be reminded about.

[Sina · Rating 4 out of 5]

As a frontend developer it is my first book about design principles and architecture. It gave me a good understanding of what are union architecture, hexagonal, port and adapters, layered, and of course clean architecture. However in the Javascript world things are different. Mapping these concepts in FrontEnd needs a lot of effort. But about the book, it is Comprehensive, easy reading and easy following.

[Unpollito · Rating 2 out of 5]

I'm very disappointed with this book. I had very high expectations of it after having read Uncle Bob's excellent "Clean Code" and "The Clean Coder", but after reading this, I can only feel that my money's only purpose was to help the author set up a second gold-coated swimming pool at their mansion - there was little to learn here.

I would divide the book in two halves. The first of these hardly bears any relevance at all - it's mostly anecdotes and stuff that (in my opinion) doesn't really need to be in a book about architecture, particularly so if you already have any knowledge of design patterns. (Seriously, why bother explaining structured, object-oriented and functional programming?) The second half is where you'd expect the meaty content to be, but at the end of the day most of it can't be summarized in a simple sentence: don't do coupling. Don't do coupling in your database, don't do coupling in your services, don't do coupling in your web frontend... and a chapter for every single place where you want to avoid coupling.

To be fair, there is a couple of gems and useful pieces of information scattered across the book, but even in these cases, many of them were underexplained. Too much attention is paid to unimportant topics and too little to the points I found the most relevant.

It is rather sad that the only chapter that I found useful from start to end is called "The Missing Chapter". Perhaps the name is indicative of the fact of how difficult it is to fit a single useful chapter into an otherwise mostly pointless book.

[Mohamed Elsherif · Rating 4 out of 5]

Overall a good book, you will learn few things from it, or at least it will be a good refresher, although it is not bringing any new ideas, worth reading if you like uncle Bob.

[Petar Ivanov · Rating 2 out of 5]

First of all, I am a huge fan of Uncle Bob. I have red "The Clean Coder" and "Clean Code" which I really found very helpful.
Regarding this book, I felt like I was reading the same thing again and again. It was all about using interfaces and hiding your business logic and implementation details. It's about using the SOLID principles into the design of your architecture. It's about using components. Also, the Microservices and SOA architectures were mentioned but I didn't liked the explanations. There was nothing about messages and events.
Overall, I do not recommend this book. It is better to read the other books from Uncle Bob but this one, in my opinion, is not worth it.

[Paul Sochiera · Rating 5 out of 5]

I didn't understand everything, yet I learned soo much and I am stunned.

This book covers every dimension, from small-scale function level to entire application-level-scale. It presents various principles for designing software that structure it logically and make development, maintenance and augmentation way easier. It also incorporates the necessary nuance.

Very strong. Though it presents advanced high-end concepts for designing large-scale applications, which aren't all super-applicable for me, I learnt a lot.

[Tomasz · Rating 3 out of 5]

Interesting, but too long with too many not needed and off-topic anecdotes. Still worth your time, but not as insightful as previous titles from "Clean X" series.

[Paul Newman]

This book was exactly what I expected it to be.

[Mher Khachatryan · Rating 4 out of 5]

Լավն էր շատ, բայց մի 2 տարի հետո 2րդ փորձ կլինի կարդալու, լիքը բաներ կային որի գիտելիքները չունեի ո�� լրիվ չէի հասկանում, չնայած էն մտքերը տվեց որ սրանից հետո ինչ-որ պռոյեկտների մոտիկանալուց ուրիշ աչքով կնայեմ։

[Madhur Bhargava · Rating 3 out of 5]

This book indeed has a lot of golden nuggets in terms of SOLID principles and their application into the whole of clean architecture, however, just as a personal opinion, as it is with all of Uncle Bob's work, it comes with a lot of unnecessary build-up(and very little of PRACTICAL code samples). I do understand that this is an architecture book and apparently the UML diagrams are supposed to be enough but it would have been nice to provide at least one good concrete Bad to Good architecture kind of sample. The content/theory itself is simply gold and provides and much needed insight into the WHY of clean code paradigm, which I enjoyed a lot.

[Maris Krivtezs · Rating 5 out of 5]

Many of the reviewers who rated it low misunderstood the book. I see in the reviews that they expected microservice, CQRS and other "architecture" descriptions. But this book is about something different. This is about the "clean" architecture. Yes he uses SOLID to describe architecture components, but from the different angle than talking about the code.
The book also is a good read just because of the style and story. Uncle Bob always is a good storyteller.
Just read and enjoy the book. Do not expect it to describe some new architecture style. Read it as a novel.

[Thiago Ramos · Rating 5 out of 5]

this is really an excelent book about creating good, reusable and disconnected from infrastructure details code.

If clean code was all about the code, this is about how you structure the code to make it more reusable, framewoderk independent and solid.

If you think MVC and Rails or Django or Phoenix is the way to go for a web project, think again with this book.

Great software does not rely on any framework. It just uses the framework when it needs.

[Nikolay · Rating 3 out of 5]

With one word – reasonable.

There wouldn't be many people who would benefit much from it. Beginners would need a lot more context and examples, while more experienced developers wouldn't learn much new. Mixing principles with a more specific suggested architecture doesn't help either.

Clean Architecture is useful to start a conversation, provoke questions, or give ideas how to explain patterns one understands on a subconscious level.

[Nariman · Rating 4 out of 5]

It's a great book on software architecture, but I wished it had more examples and case studies.

[Shayan aminnjad · Rating 4 out of 5]

This was the third book I read from uncle bob, and I think his clean trilogy is a must-read for every developer. The reason lies in what these books give you to think about. While there are hot trends(hot USELESS trends!) about "Which language is the best", "Which framework is the best" to get people to drown in, in his books, you read about discipline, responsibility, training, and professionalism. And that is what we need these days!

In this particular book, we learn about clean architecture, or how to make our software easy to build and maintain. Besides priniciples of clean architecture, the book tries to give a historical background about how the principle was founded, and this approach helps a lot to understand them.
But still this is a hard topic to grasp, and although reading this book improves your coding skills immediately, still There are many vague guidlines, which can only be mastered through training and experience. although I can imagine one takes another path, and may not agree with all the guidlines of the book, still is is a must-read for what it gives you to think about when writing code.

[Meysam · Rating 5 out of 5]

What an incredible book. I felt like my spirit was rising.

I certainly learnt a lot in this book, than I could have by redoing the same mistakes over the years.

It's definitely a must-read book.

Some of my favorite quotes:

If you think good architecture is expensive, try bad architecture.

The only way to go fast, is to go well.

Software was invented to be “soft.” It was intended to be a way to easily change the behavior of machines. If we’d wanted the behavior of machines to be hard to change, we would have called it hardware.

The architecture of a system is defined by boundaries that separate high-level policy from low-level detail and follow the Dependency Rule.

The first rule of software design—whether for testability or for any other reason—is always the same: Don’t depend on volatile things.

[Robson Castilho · Rating 3 out of 5]

Mixed feelings about this book. On one side, it explains what software architecture is about, filled with valuable design principles (at class level and at component level).

On the other side, it's a very short book, basically with a fast compilation of everything he said before. Even when he touches fresh subjects, like distributed systems (SOA/Microservices), the chapters are a little bit shallow. I've missed more code samples to clarify some concepts.

Don't get me wrong: it's a very good book, but read it as something like "the foundation of software architecture" (read the table of contents before so that you do not get disappointed).

ps.: I'd like to see Uncle Bob writing about other - and more specific - things, such as DDD, CQRS, Event Sourcing, some cloud services and patterns, etc.

[Pavel Gatilov · Rating 5 out of 5]

Clean Guide for an Architect

The book covers different sides of the Software Architect role. The conflicting collaboration of business and technology. The crucial architect's focus topics. The architecture principles derived from the famous SOLID principles and proven by decades. Some of the common architecture mistakes.

All topics of the book have bright and laconic descriptions. The are also many colorful and didactic examples to the ideas, often taken from the author's experience. And besides, there is a whole appendix chapter full of autobiographical stories.

I find this book great at presenting the essence of the Architect role and the core principles one should follow.

[Rodrigo Burgos · Rating 5 out of 5]

Is a great book, I demystified some thoughts I had about software architecture
- Be aware of how to architect your unit test.
- How to apply SOLID principles in a web service architecture
- A monolithic architect is not bad if you know the advantage and disadvantage
- Use framework but not married your business logic to them

[Mengyi · Rating 5 out of 5]

A very useful reference book that I will definitely come back to often. It makes me understand a lot more about why some architecture is good or bad.

[Adolfo · Rating 4 out of 5]

Regardless of whether the architecture suggested by Robert C. Martin (which is so similar to the hexagonal architecture) and regardless of he is right with his principles or not, I think that's worth mentioning that the book is well written and provides content that I think it worths thinking about. I recommend the book and as any other book on principles, patterns, architecture, good practices, this also has to be read with a critical mindset.

[Johnny · Rating 1 out of 5]

If you read Clean Code: A Handbook of Agile Software Craftsmanship and The Clean Coder: A Code of Conduct for Professional Programmers, you may expect something similar to those two books about architecture. However, this book here lacks the practical, hands-on advice you get with the other two books. Clean Architecture talks a lot about SOLID and decoupling. Part 5 (Architecture), on the other hand, is a rather muddled collection of shallow concepts that lack the necessary details to be helpful. Great, there is a box and an arrow and a red line – but what does that mean? How do you make those boundaries? What should you consider? This book lacks all those basic parts that every other book on architecture offers - and not in a good way where you replace the parts that everyone knows with new and unique content. This book lets you guess what those images should mean and offers no help to apply those techniques with your own code.

To prove the importance of good software design we find a case study in chapter 1. If you only skim over, then everything looks sound and supportive of the claims made by Martin. However, as soon as you look a little bit closer, the whole study falls apart. There are 6 graphs to illustrate the findings of a study. Only 2 graphs bother with labelling both axes. If you look even closer, only 5 graphs are about that “study” and they tell a rather different story than what Martin makes out of it. The last graph is the best. It is about a small experiment solving the Roman Numerals Kata and measuring the time it took Jason Groman to complete it (3x with TDD, 3x without TDD). This graph cuts off 75% of the values (by starting at 22 minutes instead of 0), what turns the difference in speed from 10% to something that looks like a 50% time saving. Using tricks like this one to prove that TDD is such a great time saver is a disappointment, especially since Martin is such a vocal proponent for TDD. Is that all he has to prove his approach?

Another great example of the problems with this book is chapter 30 (the database is a detail). He throws in a bold claim and spend the next paragraph to explain that this can be misinterpreted and that he only talks about the technology and not the data model. Instead of explaining that, he could have written what he meant in the first paragraph. The rest of this chapter is a rather generic and short explanation on why one needs databases in the first place. Nothing new, nothing helpful in any form from an architectural perspective and again so shallow that you can’t learn anything from it.

For me this book is an absolute disappointment and the worst one on architecture I ever read.

[Alan Tavares · Rating 5 out of 5]

Muito recomendado para estrutura de aplicações.
Ótima leitura e grande conhecimento compartilhado pelo Robert Martin.
Não vou dar spoilers mas vale muito a leitura para área de desenvolvimento assim como os demais livros similares como clean code e clean coders.

[Giovani Facchini · Rating 5 out of 5]

Bob describes his concept of software architecture and explain best practices and concepts used in order to achieve ease of change (evolution).

Before I have started to read this book, I thought it would focus on a top-down approach of how to design systems. Therefore, I was expecting to see a lot of database types / strategy, deployment best practices, load balancers, microservices, etc. My expectations could not have been more wrong. :)

The greatness of this book lies on showing the author's view architecture (properties that allow software to change and evolve), the history of programming paradigms and how they take away features to improve safety, the SOLID principles (SRP, OCP, LSP, ISP, DIP), the trade-off between component cohesion concepts (REP, CCP and CRP), and a lot of other things focused on making change easier.

I understand and realize that many controversial topics are covered and so there is some anymosity around about this book. For me, it was great because it will help me to understand better how certain decisions in projects were made and get less frustrated with legacy systems.

There are a lot of concepts in the book, so you better take notes while reading the parts and concepts you believe will be useful to you.

[Martin Nachev · Rating 1 out of 5]

1.5/5

The only useful chapter of this book is the final one by Simon Brown taken from Software Architecture for Developers. The rest of this book is totally useless if you've read Clean Code.

"Clean Architecture" is a very theoretical book, mostly filled with stories from Uncle Bob's past. The SOLID principles are repeated once again, and only a very small part of this abstract book is actually focused on architecture (where the concepts are roughly explained with no practical examples).

At the end of the day, I wouldn't recommend this book to anyone. People already familiar with the concepts won't learn anything new, and I doubt beginners will understand them adequately from this book alone. Unlike Clean Code and Clean Coder, Clean Architecture is a waste of time. There's no real substance and I struggled to read it through to the end.

[Sergey Teplyakov · Rating 2 out of 5]

The book isn't bad, but not very practical.

All the principles described in the book make sense once you understand them and saw issues in practice. But what if you unfamiliar with them? What if you want to understand them? In this case, the book wouldn't help: the chapter dedicated to design/architecture principles are very short without any practical examples.

Lack of examples is the main problem though. It is hard to provide good samples for a design/architecture book but without them, it is hard to generalize the knowledge to your projects. The author provides a few examples with a very high-level description, but they're not very useful.

It is an ok read, but only if you know everything and just want to remind yourself about design/architecture principles. But if you want to learn stuff, I don't think that the book will give you an actionable guidance for you.

[Wojtek Erbetowski · Rating 4 out of 5]

This book was exactly what I expected it to be.

I have attended several talks by Uncle Bob and read his 'Clean Code' a long time ago. I wasn't surprised by the contents, as his stand on the architecture (as it seems to me) is consistent and stable. Some of his war stories are hard to overvalue.

The most important part I have read there is about SRP and how to understand it differently than it's commonly understood.

I recommend the book to most software engineers, to both learn, and get a topic to discuss during tech events.