loading...
Cover image for Why I can't recommend Clean Architecture by Robert C Martin

Clean Architecture Why I can't recommend Clean Architecture by Robert C Martin

bosepchuk profile image Blaine Osepchuk Originally published at smallbusinessprogramming.com ・7 min read

Clean Architecture failed to meet my expectations on a number of fronts. Despite Mr Martin's obvious passion for the topic, Clean Architecture is poorly organized, lacks examples, and is silent on working with existing systems. The author missed a major opportunity to teach us when and how to apply these lessons to our own systems. Let me explain.

Clean Architecture is a poorly organized book

This book takes a long time to get going. The chapters on design paradigms (structured, object oriented, and functional) seem particularly out of place and unnecessary.

The chapters on the SOLID principles are good. I enjoyed seeing the principles broken down and explained well. And I found it interesting to think about their applicability to system architecture. But Uncle Bob presents the SOLID principles like hard rules, which rubbed me the wrong way. In fact, I'm pretty sure a system that never violated the SOLID principles would be a giant mess.

However, this paragraph from page 137 is important:

The primary purpose of architecture is to support the life cycle of the system. Good architecture makes the system easy to understand, easy to develop, easy to maintain, and easy to deploy. The ultimate goal is to minimize the lifetime cost of the system and to maximize programmer productivity.

That's a great observation. Why didn't Uncle Bob put it in the first chapter?

Not enough examples

There are hardly any examples in this book. Chapter 33 contains an example that discusses a video sales e-commerce application. It's okay. But I didn't walk away from it with a firm idea of how I'd apply the concepts to my own systems.

The appendix tells the story of how Uncle Bob came up with the SOLID principles and the rules of clean architecture. It's loaded with examples of past projects. I think it's the most interesting section of the book.

The book is silent on improving the architecture of existing systems

Most developers spend most of their time working on existing systems. So, I expected Clean Architecture to be full of advice on improving existing systems. But the book is conspicuously silent on the subject.

How to create a clean architecture?

In the first half of the book you'll learn that you create a clean architecture by following the SOLID principles to break your system into components along your system boundaries (I'm paraphrasing). If you stopped reading there, you could be forgiven for having the impression that Uncle Bob would not approve of whatever you've been doing for architecture. You could also be forgiven for thinking that the few options he presents are the "right" way to do things. Yet towards the end of the book you'll read this on page 228:

This example is intended to show that architectural boundaries exist everywhere. We, as architects, must be careful to recognize when they are needed. We also have to be aware that such boundaries, when fully implemented, are expensive.

At the same time, we have to recognize that when such boundaries are ignored, they are very expensive to add in later—even in the presence of comprehensive test-suites and refactoring discipline.

So what do we do, we architects? The answer is dissatisfying. On the one hand, some very smart people have told us, over the years, that we should not anticipate the need for abstraction. This is the philosophy of YAGNI: "You aren’t going to need it." There is wisdom in this message, since over-engineering is often much worse than under-engineering. On the other hand, when you discover that you truly do need an architectural boundary where none exists, the costs and risks can be very high to add such a boundary.

So there you have it. O Software Architect, you must see the future. You must guess—intelligently. You must weigh the costs and determine where the architectural boundaries lie, and which should be fully implemented, and which should be partially implemented, and which should be ignored.

So more than half way through the book he says that it is up to us to decide where we should put the boundaries in our systems. And that boundaries are potentially everywhere. Confusing, right?

What this book is missing

So, if the ultimate goal of software architecture is to minimize the lifetime cost of the system, shouldn't a book on architecture help an architect make those decisions?

Unanswered questions

This book left me with a lot of unanswered questions. Where is the discussion of the economics of the various options? How do I find the optimum architecture for my system? Where's the research?

unanswered questions

How do I decide if horizontal layering or vertical slicing or something else will minimize the lifetime cost of my system? Or if I have no clearly defined layers, how do I decide which, if any, layering strategy will minimize my lifetime costs?

I have even more questions. Where should you put your effort if you have a limited amount of time to improve the architecture of an existing system? Is separating the database from the business logic is always a good idea? Which advice should you always follow? Which advice depends on the system?

Details that would have made Clean Architecture more valuable

In Code Complete, Steve McConnell talks about the tradeoffs between different non-functional requirements like reliability, dependability, correctness, maintainability, readability, etc. He explains how some requirements move together and others conflict. I would have loved to see something like that for the architecture decisions discussed in this book.

In Clean Architecture, project size, team size, the consequences of project failure, expected code lifetime, and other important factors are under-emphasized as drivers of architecture. For example, Healthcare.gov needs more architecture than the personal to-do list you are developing, even though they are both web apps backed by databases.

What this book is really about

I spent the majority of this book slightly confused. I kind of understood what Uncle Bob was trying to say. But didn't completely get it until I read the appendix. So, let me save you some time.

An example

Imagine you are building a desktop computer for the consumer market (office computers for example). You get to choose the hardware and you are going to write the software for the whole thing (firmware, OS, drivers, applications, everything).

Would you write a monolith?

How would you go about it? Would you write a giant program (a monolith) where the code for the spreadsheet knew about the kind of disk you selected for your computer? Can you imagine updating the spreadsheet code and adding 'if' statements everywhere so that it does one thing if you have a SATA drive and another if you have a SCSI drive? And then doing the same thing for VGA vs DVI vs HDMI video? What about different paths for PS/2 vs USB mouse input? And then repeat the process for the word processor and all the other applications you intend to bundle with your computer?

That would be a nightmare to maintain, right? So what's the solution? Architecture! Your spreadsheet shouldn't know what kind of mouse you're using. Nor what kind of display you have. It should be completely oblivious to those details.

Boundaries in your computer

And that's what you'll find if you look at your computer. There's embedded software in your mouse that communicates with your operating system. Yet the details are hidden from your applications. Your spreadsheet accepts standardized input without knowing or caring what kind of mouse you are using. Then when someone invents a new input device like the touchpad it works with your spreadsheet automatically.

That's just one of the boundaries in your computer. You'll likely come up with hundreds of them. You might assign different teams to work on different parts of the system. You might create or adopt different specs for the various ways the different components interact.

You're probably saying 'duh' at this point. It's obvious that you wouldn't want to change and recompile your spreadsheet every time your hardware changes. Maintenance would be a nightmare. And I agree.

Boundaries are your friend (if you use them correctly)

It's easy to see hardware boundaries. But the same logic that makes hardware boundaries worthwhile also applies to software boundaries. Software boundaries are just harder to see.

So, you might start with the ability to display the spreadsheet on the screen. But you might also want to save it to disk, save it to PDF, save it as a CSV, or print it. So, maybe one of the boundaries in your spreadsheet program is to have an internal data structure that represents each spreadsheet. And then you pass that structure to different code to display, save, or print it in the desired format.

If you keep the data structure completely unaware of how it is displayed, saved, or printed, then you can add a "save to XML" feature down the road without digging through all the code related to the spreadsheet data structure. And if that spreadsheet data structure is several million lines of code, you can imagine how much easier that would be.

That's all Uncle Bob is trying to tell us in this book. You can use the SOLID principles to create boundaries in your systems that hide your implementation details, reduce complexity, and help you reduce the total lifecycle cost of your systems.

A better software architecture book

In many ways, Patterns of Enterprise Application Architecture by Martin Fowler is far superior to Clean Architecture. Fowler describes the patterns he's observed repeatedly in enterprise applications. He gives a simple example if each pattern, describes how it works, and where to use it. I found Patterns of Enterprise Application Architecture to be very readable and applicable to my systems.

Takeaways

There is valuable information in Clean Architecture but you have to work to find it.

I found the chapter on embedded software one of the easiest to understand. It intuitively makes sense to avoid scattering low-level calls throughout your code base. And it also makes sense to make your logic testable in the absence of the hardware (especially since embedded software is often developed before the hardware is available). If you could only read two chapters of this book, I'd recommend you make it this one and the appendix, regardless of what kind of software you write for a living.

Overall, Clean Architecture is a tough read and Uncle Bob left me with more questions than answers. I definitely wouldn't recommend this as your first book on software architecture (check out Patterns of Enterprise Application Architecture by Martin Fowler instead).

Agree or disagree. I'd love to hear your thoughts.

Enjoy this post? Please "like" it below.

Posted on by:

bosepchuk profile

Blaine Osepchuk

@bosepchuk

I'm a small business programmer. I love solving tough problems with Python and PHP. If you like what you're seeing, you should probably follow me here on dev.to and then checkout my blog.

Discussion

markdown guide
 

Thanks for your recension of the book.

I've bought Clean Architecture, and it is on my short list of books to read. I'm curious if I'd share your opinion after the lecture.

You wrote:

"Uncle Bob presents the SOLID principles like hard rules"

That's all Uncle Bob. You like or hate him. He is sometimes very controversial. I have some distance to his opinion, but I want to hear what he has to say.

 

I personally don't find him controversial. I remember his deal about "Monads" which were just plain wrong.

To be honest with you since his book Clean Code - which I must say is to me a book that every software developer should read - I do not really see what he brings on the table for today's real world problem or to challenge the state of art of software engineering. Therefore I do not find him controversial at all, he likes himself a lot and is convinced that he's right.

Kent Beck, Martin Fowler, Alistair Cockburn, Eric Evans and many others have a far more impact, I think than Uncle Bob and are much more humble which to me, is a quality which goes with intellectual honesty.

 

I just read Robert Martin's "WTF is a Monad?" presentation (slide deck, in PDF format), from about 10 years ago.

Hoo-boy, swing and a miss. Complete misunderstanding of monads.

Clean Code is a fabulous book. (Two thumbs up!)

I've not read The Clean Coder nor Clean Architecture.

Given Blaine's review, probably won't be putting Clean Architecture on my short list. Which is okay, I've already got too many books in my book queue as it is. I try to use my time to read high quality book with good signal-to-noise ratios.

However, I did not get off scott free... now I've added out Patterns of Enterprise Application Architecture by Martin Fowler to my short list.

The Martin Fowler's book is a treasure ! I agree.

This "WTF is a Monad?" was quite messy I agree !

 

I remember his deal about "Monads" which were just plain wrong

What is the story on this "deal"? I have not heard about it.

Well a while ago he posted on Twitter a statement about what a Monad is. Which gave an epic thread and some discussion on diverse communities.

Here's the Twitter thread, some discussion on Reddit

He also made a talk about Monads (also wrong) which you can find the link on this Meetup page

There other "controversies" like his stand on the guy who got fired of Google or his "tests solves everything software related" philosophy, I took the one about Monad because its less opinionated since a formal definition of a Monad exists and it's not what he said.

 

Yeah, there's a real cult of personality issues. Certain "rules" also are highly context-dependent. Like "sure, that makes a lot of sense for Java developers..."

I like the reading material, I don't really like that it's treated like gospel.

 

Back in the day, maybe it was a major revelation and everyone loved (wanted?) to listen to the "expert". 😑

 

Absolutely. Post back here when you finish reading the book and share your thoughts.

 

I finished the book, so finally, I can write a comment after my reading. My first thought was to defend the book at any cost. I've been even thinking about a blog post about it. Finally, I'll only leave this comment. Blaine keeps in mind that I've nothing against your opinion. I respect others beliefs and feelings. Please, don't take this personally.

So let's start.

"Clean Architecture is a poorly organized book."

I can't agree. The book as a whole is well organized. Of course, there are chapters which in my opinion are unnecessary like mentioned by you chapter about design paradigms_. I share your view that sections about SOLID principles are excellent. But I think that Uncle Bob spends too much time describing those principles at this book. In my opinion, they should be mentioned, and there should be a piece of information that knowledge and a well understanding of them are required to read further.

"Not enough examples."

Holy true. I've nothing to add. I think the same.

"The book is silent on improving the architecture of existing systems."

True again. There is only one chapter which describes the example location of components across multiple libraries, but it concerns newly created projects.

"What this book is missing"

  • Unanswered questions.

Yeap, a lot of unanswered questions. I had a feeling that I'm Neo and Uncle Bob is Morpheus from Matrix, and he gives me a choice between red and blue pill without telling details.

Morpheus's pills

  • Details that would have made Clean Architecture more valuable

Here I disagree. The message from "Clean Architecture" by Robert C. Martin in that boundaries are the most important thing. We can organize our architecture in several ways depending on a project's needs. Furthermore, our architecture will evolve, and there will be a day we will need to reorganize our components. So we need to keep in mind to set up right, firm boundaries in our system. BTW you mentioned about boundaries in the section "What this book is really about."
I also think that database or www server is only a detail in our architecture. Thinking in that manner helped me multiple times.

Appendix

I think that appendix which is a part of Uncle Bob's professional resume doesn't add anything. Yes, it's a beautiful story and a beautiful piece of history, but it's loosely coupled with the primary aim which is Clean Architecture.

To sum up, I also feel that "Clean Architecture" isn't dedicated for beginners and every reader should at least have experience and understanding of SOLID principles. At all this is not a bad book. I think that Robert C. Matin fans won't be disappointed. If you've read other Marin's book and you like his style of writing, I believe you will be satisfied. If you are an experienced software architect, it's possible that you will be bored during the reading. But again, that is only my subjective opinion. Please don't treat me like an oracle because I'm not.

Cheers.

Nice summary, Rafal.

I'm not an oracle either and I can see how you arrived at your opinions. I'm not offended; it's nice to show people see opposing points of view and let them decide for themselves.

 

I m pretty happy he didn't provide any concrete example because everyone despite of tech stack can grab the idea and implement it.

Are you that ignorant? There is still code being developed and maintained in COBOL, ForTran, and mainframes. Young developers wil always assume newer languages will take over only to find out non SV startups don’t act like that

Hey Robert, while I agree with the point you were trying to make, you need to use a more constructive tone in this community. Since this is you're first comment, it's all good. Just make sure to give the folks on the other end of the internet some benefit of the doubt in the future.

Only such architectures, patterns and practices will sufficiently meet the rise of AI-driven programming. Imperative, class-based-OO, brittle languages like Java and even Python (which still does not have multi-line anonymous functions for God sake) will feel their age as dynamic, fluid languages like modern JavaScript, Go, Crystal, Julia, R and others take over.

This sounds like a great beginning for a movie about the rise of AI programming. :D

 

It's interesting you were slightly confused throughout the book.

You had issue with the fact that the book doesn't seem to get to the point or practically give you enough examples on how to fix your current architecture. (I've paraphrased, of course. If I did so unjustly, please correct me).

May I address these two points?

1. The book builds up many ideas laterally before building on top of them.

  • One example is the programming paradigms, which you mentioned.
    • This is appropriate because it tells of how our language/paradigm choices impact our architectures.
    • Those four chapters are also in the progression that we as an industry have taken.
    • Furthermore, they tell of the evolution of ideas and each paradigm simultaneously (a) builds on the previous' strengths and (b) introduce new cost, or analyses, which must be weighed and mitigated.

Admittedly, some people don't learn well this way.

  • They prefer to grab code examples and tweak things
  • They learn by banging their heads against the problem, rather than listening to stories, anecdotes, etc.

I'm not one of these people, but maybe you are. Or maybe my bullets don't capture the nuances of your learning style, and you have some genuinely hard problems that you believe this book's rules and principles don't help you solve.

For that I apologize, on behalf of myself and Uncle Bob.

I've seen every video on YouTube that has Uncle Bob in it. I've also read a lot of his blog posts.

  • Maybe this makes me seem like I'm in the cult of personality, but I disagree plenty with him.
  • Maybe this gives me "a leg up" in appreciating this book, because I have many of his recorded thoughts to use to filter, augment, or fill-in any argument that feels a bit hollow.

And may I just assert why he holds something like SOLID as hard rules?

  1. He compiled them (over years, talking with colleges)
  2. I've seen codebases that treated all of the principles as law. And they are excellent architecturally
    • They look different, though. They are a little weird to look at initially, because (for a Java codebase) so many interfaces are short, and so many class and method names are more than two words
    • Yet, they all have less than 4 parameters.
    • Adding new features is a breeze
    • You can read the code as near-coherent English language.

That could be too anecdotal. But I haven't seen the evidence that the effort is not worth it.

2. Practical examples were few and far between.

I think you bought the wrong book. This is a book on principles.

  • Time and again, Uncle Bob tells us that we, ourselves, must make the determination as to what is more important throughout the life of the system.
    • Part IV, "Component Principles", is laden with statements like:

A good architect finds a position in that [component cohesion] tension triangle that meets the current concerns of the development team, but is aware that those concerns will change over time.

or

Indeed, there is probably no correct order [to this dependency cycle]. This can lead to problems in [certain langauges].

He then goes on to explain how to employ a principle in a that particular problem scenario. And I would say that is the value in this book.

  • Rather than a bunch of code example from which you have to extract the code examples, time after time he presents the problem and a principle or two that addresses that problem directly.
  • He also putting more faith in the competency of you, the developer, to make similar analyses to what he makes throughout the book and to take appropriate action in your projects
    • He taught us how to code this stuff already: Clean Code
    • This was a higher-level, but I think, more profound book that coveys principles.

From the foreword, Kevlin encapsulates this idea:

To walk this path [to good architecture] requires care and attention, thought and observation, practice and principle....

The only way to go fast, is to go well. -Uncle Bob

Enjoy the journey

 

Your comment resonates with me because you specifically discuss principles. The world we live in is highly polarized. Software development is not immune to this issue. As we gain experience as professionals, we will naturally accumulate opinions on how things should be done. This is OK. Our strong opinions relieve us of indecision. They give us a jumping off point. They help us navigate difficult problems quickly, and with confidence.

The danger is in what can happen if our opinions become absolute rules. If that occurs, our problem solving will be formulaic. Rules only apply in specific situations. Therefore our designs become less flexible, and we will have trouble with new classes of problems.

Principles can help. We should analyze our own opinions, as well as the opinions of others, and try to discern what the underlying principles are. Take the D in SOLID. DRY is a principle and is always a valid approach. However, the degree to which we apply DRY is not an absolute. This is born out with countless StackOverflow questions where people are tying themselves, and their code, in knots to try to inappropriately reuse a particular class across multiple domains because somehow they got the idea that DRY is a rule.

Learning to think, and design, in this way is a skill that comes through practice. When we first start off, there's nothing wrong with following a few absolutes. However as the scope of our responsibility grows, so must our ability to throw out those absolutes. Think of it like teaching a child that the stove is hot. When they are very young, we might tell them only that they must never touch the stove, a heater, the hot metal of a car, or a light bulb. As they get older, though, we expand on that and explain in simple terms why they must not touch these things. As they get continue to grow, we might explain in more detail the dangers of high heat. Now, we are no longer telling them specific things to avoid, but giving them a principle to help them avoid any kind of burn.

Is Clean Architecture full of Uncle Bob's opinions? Yes, and that's just fine by me. He has a lot of experience, and he's chosen to share some of it with us in the hopes that we might have an easier time. His opinion is no less valid than anybody else. We all have different experiences, and therefore different opinions. If we can learn to extract the principles and use them to augment our own experience, then we'll be better off as individuals and as an industry.

 

No book is going to work equally well for everyone. I found this book quite unhelpful and, based on the comments here, I'm not the only one. But based on your summary and several Amazon reviews, many people find the book valuable. So the reviews are split.

Clean Code is one of my favorite programming books, as it is for many programmers. And I just wanted to share my review of Clean Architecture with my colleagues on dev.to so that they might think twice before investing a significant amount of time reading this book.

Thanks for taking the time to share your thoughts.

 

I've seen codebases that treated all of the principles as law. And they are excellent architecturally

Please share with the group if you can. I'd love to see what that looks like when it's done well.

 

I am sorry to say but this is a very poor article, strongly your opinion based. Probably you misunderstood it or you lack the necessary experience to understand its benefits.

Clean code Architecture is one of the best book I have read about good code. I have worked in 5 different companies in my carrier, and in all of them I have seen all the situation described by the Robert Martin in his book.

In the same time I have encounter a lot of developers who thinks they know everything, even with 2-4 years experience only, but not able to produce a single application that is testable maintainable and scalable on the long run.

I use to say today we have code writers, not software developers.

Software development should be a discipline with good rules that comes from experience and science based, same as a building architect, he uses math and specific rules to design a building.
Those rules does not change from language to language or from time to time.

Consider that:

  • Consider that Robert Martin has more than 40 years of experience in the area, double more than you and me together
  • Software developers today lack of Humility, Honesty and Courage
  • His book is concise, short and well explained, on the other hand I find his videos long with many examples
  • To avoid opinion based comparison take in consideration numbers, data (uncle bob does this).
 

I saw no data (aside from his personal experience) or research that supports the positions Uncle Bob expressed in this book. There's no science here. It's all his opinion.

Steve McConnell, on the other hand, cites hundreds of studies in his books.

And I've been at this for 19 years so it's doubtful that he has more than twice as much experience as both of us put together (although I know of no research that says that people who have more experience write better books than people with less experience so I doubt it’s relevant).

Anyway, thanks for reading my post and taking the time to add your thoughts to the discussion.

 

I wouldn't say it is opinion based, Uncle Bob mentions a lot of other authors in his book.

Design patterns, Solid principles, TDD, code form (class length, function names ect...) by definition ... are not really opinions. They are solid computer software theories and models consolidates over years of computer theories, Uncle Bob just emphasizes them in his way.

I have applied Uncle Bob teaching both at work and on personal project... the benefits have been huge, bug density lower, able to fix problems and scale projects with new feature much faster.

I always advice software developers to leave behind personal biases, be open mind, try, compare with data bases and value experience.

That's pretty much the definition of opinion. The opinion may be shared widely and have great support among "experts" but that doesn't make it science or fact.

I follow much of Martin's clean code advice. I believe it is effective for my projects. But, again, that's not proof in the same way an engineer can prove that the bridge she is building will not fall down.

For example, in "Code Complete" Steve McConnell reviews the research regarding function length. And the research doesn't support the idea that very short functions are beneficial (as Martin asserts). Now you might take issue with the methods or techniques employed in the research but you at least have something to look at and evaluate. Whereas Martin just says that methods must be short (with no offer of proof).

Theory of relativity is not opinion based, same as gravity, same as computer theory...
Uncle Bob support the Single Responsibility Principle, a function should do one thing and do well, and a long function does a lot of things.

Again you're wrong here, Uncle Bob does just says method must be short, he brings up different examples with charts, comparing bug density of different project (at least in the videos, do not remember in the book).

Have a look here at lest
softwareengineering.stackexchange....

You serious with this stuff?

You think the ideal length of the function is on the same footing as the acceleration due to gravity being 9.81 meters per second squared?

If you did not get that, then is useless we discuss about it.

I am serious on the stuff, the computer theory is an exact science, software patterns and models, are not opinion based, and are proven with years of experience and studies.

I can relate you to thousand of article that says the same thing, function length was just an example
swreflections.blogspot.com/2012/12... but I am not going to do that research for you now.

What I am trying to say is that experience and studies have consolidate these things, has nothing to do with opinion based as you say, even you disagree, the best thing to do is to commit to them.

The hardest thing I had to deal in coaching my work teammates, was convincing them that coding using clean code principles was the right thing. Some they were young, unexperienced, other thinking they could write the best code (which only they understand) and the resistance to change thebalancecareers.com/what-is-resi..., are some of the factors you had to deal with, which I think is your case in your article.

And I do not bias you for this, I work everyday with strong opinion based colleagues who thinks "yeah that 1000 line spaghetti code is easy just change that and that"... and loose 7 days on fixing a simple bug, and other 10 trying to extend that code.

I take Uncle Bob for grant, because he has a great experience, he describe exactly what is happening and what will happen in your job, he is not the only one saying those things, and he is basing his writings on theory, studies and solid fundamentals, not on opinion.
And lately especially because I have experienced, tried the benefits of writing clean code.

Again my advice is, be open minded, try, compare, check the benefits, use data and numbers not feelings and opinions.

This web site is a great source of examples if you need one:
refactoring.guru/refactoring/smells

 

In my opinion Clean Architecture is a typical Uncle Bob book. And if you know other books from Uncle Bob, you will find nothing new in this one. I found this aspect a bit disappointing, too.

The last refreshing new book about architecture that I've read was this one: Langlebige Software-Architekturen (long lasting software architectures). It has a completely different approach, it's much more practical and comes with scientific analyses of existing code bases. Unfortunately it's only available in German AFAIK.

 

Interesting. It's too bad I can't read German.

 

I would not recommend anything named "Enterprise" in 2018. And the book you recommend is nothing but good for first time readers, it gets into too many details, in too many patterns that are obsolete, you will end up learning too many things and remembering none.

Clean Architecture lacks a lot of stuff, but as a starter in Architecture is good overall. I read it in a few hours, it's "light". In a case, by not being so great and long, it is a great start for a developer to delve in the Architecture world, by using the same concepts he uses to code (SOLID).

My point is, even if it is a poor written book, from the Clean Architecture the reader will probably retain only 2-3 things, the "onion" schema probably is the most important, which is fine. They are powerful simple concepts that will not die of old age (like the patterns are).

Unfortunately most of these similar books are stuck in the past, with Java/.Net monoliths, which in my non-enterprise world they are obsolete. I'm still waiting for the "new age" books that takes advantage of the new advancements in the computing area.

 

Are you poo-pooing the Fowler book because it has the word "enterprise" in the title?

Either way, I'd take the Fowler book over Martin's book every time. Yeah, it's from 2002 and some of the info might be dated but it's still a solid reference. There are only so many sane ways you can compose enterprise software and Fowler has done a pretty great job of cataloging them.

 

The essence of Clean Architecture would have fit nicely into a single, albeit maybe somewhat lengthy, blog post.

The filling material which makes up about 70-80% of the book, is also not per se of bad quality. It mostly reiterates rather basic concepts, but I'd qualify it, depending on the how experienced a reader is, as too shallow for an in-depth treatment or too bloated for a high-level overview. And the unavoidable morale tales from Bob Martins projects are also entertaining, but I personally don't seek entertainment in software engineering books.

I think, it can be worth skimming, but I don't consider it an essential read.

 

Nice summary, Fabian.

I had the same idea about the book fitting into a long blog post but it didn't make it into the final version of my post.

 

I found Clean Architecture pretty underwhelming. It's good on the SOLID principles etc. but his view of the generic architecture feels too restrictive and a little wrong-headed. You'd be better of reading something like:

dossier-andreas.net/software_archi...

 

Thanks for the link, Ian. It's a clear and succinct introduction to hexagonal architectures.

 

Have any of you ever looked at the source code from his project Fitnesse? in his book he mentions it over and over. I have looked at it and what I see is a mess. He mentions "screaming architecture", but his code does not even come close. I found all components he menions, but none of the bear the names he mentions either.
Use cases are Instructions, RequestBuilder factories are just string formatters to create urls, .... He also makes the mistake that many other developers do: let the controllers take care of calling the presenters.

In many languages like .NET, you don't have full control over the return format, so not only does he force another level of abstraction, he doesn't even follow his own rules.

In a perfect world of theory, all his recomendations sound solid, but in the real life I find them very poorly applicable.

 

I haven't looked at the source code for Fitnesse. But I wouldn't be surprised to learn that practice and theory have diverged.

And, just to be clear, I don't think that says anything bad about Uncle Bob. Software development activities in real-world systems need to make economic sense. Often that means leaving "good enough" alone even if that means the system doesn't meet all your architectural goals.

If Uncle Bob and his son are the only two programmers on the Fitnesse project, the architecture might be perfectly adequate as it is. But if they were going to bring in ten additional programmers it might be completely inappropriate. Context matters.

You wrote:

In a perfect world of theory, all his recomendations sound solid, but in the real life I find them very poorly applicable.

That's probably true for the smallish (100 KLOC class) systems I've worked on. But the bigger the systems get and the longer they are going to live, the more important architecture becomes. For example, I wonder what the architecture of the F-35 software looks like (reportedly around 8 million lines of mostly C++). I'm guessing/hoping it has a lot more architecture than my 100 KLOC projects.

 

I've bought some Fowler books but every time I read one I'm reminded of the needless abstractions that clouded pertinent information when I was reading the Gang of Four book. I'm struggling through "Clean Code" by Robert Martin right now and I'm feeling the same way as the author of this article does about "Clean Architecture". Seems a lot of filler that is basically nitpicking. I'm not sure how many people are interested in a graph depicting average Java function lengths and how it is relatable to day-to-day programming concerns.

One point I really enjoyed in this critique by Mr. Osepchuk is the lack of time spent on dealing with existing code ("legacy code" as people are fond of saying). You are darn lucky to work on a brand new codebase - you are working on existing codebases for about 90% of your career. Nope, you're not going to be re-writing that $500 million dollar website on Node/React when the PHP implementation is humming along just fine.

 

Thanks for the heads up, @bosepchuk . Uncle Bob has some useful things to say, but I tend to approach his material with some caution already.

By the way, I also want to thank you for indirectly inspiring my most recent article, which I just published on here. ;)

 

I'm honored. BTW: I read and enjoyed your article--very insightful.

 

Thanks for sharing your thoughts. A few weeks ago I started reading Clean Architecture and even though I found the first few chapters really interesting I was worried that I would end up learning nothing about how to actually build large complex software. I'm not actually interested in reading another book on SOLID.

I'll take your advice and start reading Patterns of Enterprise Application Architecture.

 

I agree with some book organization problems. I have also expect more, but I still consider the content very useful.

If you need examples, you have a lot in the clean coders video series, that is imo more useful that the book.

My very subjective impression was that Uncle Bob does not want to favor the book over the video series, that could be a valid argument.

 

Thanks a lot for this review. I am putting Patterns of Enterprise Application Architecture on my To Read list.

What are your thoughts on Architecture of Open Source Applications?

 

Surely software development is far-far from being science. Till this day it is more an art, unfortunately. Value/advantage of most concepts (TDD, Clean Architecture, SOLID, OOP etc) is not substantiated by any scientific research. For a scientist, the never-ending discussions about these concepts should stop after a single scientific paper, stating that "such a such groups of developers were given a task ... under such and such criteria, and it was found that those who followed concept X produced 20% more value for the same time and 67% of them said that they also felt more satisfaction as compared to those who didn't follow it." But there are practically no such papers. (I remember only one scientific paper on comparison Scala-vs-Java development speed, but it remains unknown for 99% of Scala and Java devs.)

 

I agree. We could benefit from more scientific research about what works and what doesn't in software development. Thanks for your comment.

 

If your are interested by DevOps good practices back by science, read this excellent Accelerate book

You won't find SOLID, or OOP in there, but automated tests (and TDD), and Architecture.

 

I really like that book, and the concepts presented there. Here some comments to make you more happier about this book. I don't have access to the book right-now, I will not be able to give precise references. I will have to buy this book again. I could buy yours ;)

The Goal of architecture is addressed right at the start in the introduction. He won't go into details but it's clear. The goal of architecture is to optimize people work, not the system. Given a flat listing of all the code for a system, without boundaries or already decoupled classes into components, you and me, with different set of constraints won't derived the same architecture. Both being "optimized" for our own purposes. So there is no path to follow.

Also, adding to that, software is a living beast. You may have optimized your architecture for today, but some other day, you have to admit, things have changed. The environment, the teams, the tools, the software...

You focus a lot on the SOLID principles, but those are at the design level. They are the foundation to understand the package principles. You have to focus more on those 3 package principles and the tension space they form (it's all about compromise).

The book is about teaching principles. The recipe is following them.

Comparing Clean Architecture with Code Complete isn't fair, or is comparing apples and oranges. Code Complete is at the code level/line level. At most considering a couple of lines together, to form a class definition or a function. The scale and complexity of such elements are small and simple (but I won't explain them to my Mom ;) ). Opposite to that, in the continuum describe in the book, is architecture. You draw rectangles and arrows, but the complexity implied is so huge.

Chapter 2 is my best : A Tale of Two Values. If you have to convince a non-techy-manager-feature-oriented-I-know-nothing-about-software-development to let you structure your code, that is doing architecture, that chapter could gives you bullets. Otherwise, you will craft a Monolith. Because, you won't get up a morning with the idea "Lets build a Monolith today". Those managers make you build one (and yes, we let them do). And it's also typical for a start-up, where you have to focus on features.

I will certainly give a try to "Patterns of Enterprise Application Architecture", by Martin Fowler. I really like his work. And I totally agree (finally) that "The chapters on design paradigms (structured, object oriented, and functional) seem particularly out of place and unnecessary." I also appreciated the appendix recapping Bob's career and the polymorphisme applied to hardware.

 

I have a hard time following your reasoning why this book is not recommendable.

You state that the stories on design paradigms were unnecessary, yet you miss to say why. So why you think these were unnecessary (beside the fact that he basically told a story before any chapter he started in that book)?

You are stating that there are too few code samples in the book, but then the book never advertised to be a code repository (in any of its pages) or explain paradigms and principles by code.

And I would say that it's not what the book is about. It's more about a way of thinking as an architect than which code or programming language is explicitly used to create a good software architecture (he states that several times in the book btw). If he would have done that, which language you think he should have used? And what exact implementation would have been good or bad?

There are always tons of ways to implement something and if talking about principles and paradigms, that would have put some heavy burdon on him and any presented implementations.

Let me clarify what I mean:
We all know it, you are implementing some boilerplate code just for a test project of yours. Very dirty, just as a proof of concept. Still, there will be people coming to you, looking at the code, starting to tell you that there are more effective, more efficient, more beautiful, better maintainable ways (append arguments here endlessly) than the test code you have just written. And they start "enlightening" you from all possible perspectives.
They expect from you to defend your decisions while all you think is "hey man, I just wanted to see how that pattern works...".

Look at the reactions about your blog posting, very divided. This forces you to answer and justify yourself and your opinion.

Now think about his book and what would have happened if he had included sample code for his presentation of general insights on clean architecture. Eventually, that would have forced him to explain how the presented code fits the all-so-good architectural paradigms he has just talked about. Also 20 years from now, would that implementation still be valid or would other languages or implementations that will arise be more fitting? See my point?

Presenting implementation examples will inevitably force you down a road you cannot get off from and therefore he simply avoided putting that burdon on him (probably there wouldn't have been an implementation that fits it all). He stayed theoretical with a groundtruth that comes from practical experience. He didn't want to get too explicit about it.

I mean look at the blue book by Eric Evans about DDD. There is as good as no code at all in that book (500+ pages btw...phew), still it's the key work to the whole DDD world and that Martin Fowler states to be one of the biggest influences he had concerning DDD (while still saying it's hard to read).

And you may have misunderstood that this book is not about THE architectural way of doing things. Rather it's a summary of all the clean architectures that presented themselves over the years. Layered, Hexagonal, Onion, Microservices and all the shebang. They all have the same thing in common, they are clean architectures. They follow the dependency rules, they allow decoupling, they cherish maintenance and testability and they allow to use little human resources to gain high production value.

The book by Fowler you recommend is great, but it's a different book with a different mindset and a different goal than clean architecture.

It's like saying Eric Evans book on DDD is bad (because it's mostly theory) and Vaugn Vernonts book on IDDD is good (because it's tailored against practice). This is simply a biased opinion, which is fine but it's not fair to expose it as if it wasn't.

To me, Clean Architecture is the perfect summary of all the principles and paradigms that play a key role in the world of architectural fundamentals. Nothing more but definetly not less.

 

Thanks for sharing your thoughts, Samir.

Clean Code taught me how to write clean code. It was full of examples and it was logically organized and easy to understand. I can (and do) give it to juniors and tell them to read it and apply its lessons to their code and they can do that successfully.

But I can't say the same the things about Clean Architecture. It certainly didn't teach me how to create a system with a clean architecture and I believe it would be a waste of time to give it to juniors and expect them to be able to create better architected code.

I believe many people purchased Clean Architecture with the expectation it would be on the same level as Clean Code (one of the best programming books of all time) and it's not.

With that said, plenty of people rated it 5 stars on Amazon so you're not alone in your opinion.

 

Nice summary, Blaine.

While I love this book (I am only 60% done with it), I am self-aware that I tend to get carried away easily and hence I need to read opposing opinions before I make up my final decision, which is what brought me to this post.

Following are a few things with respect to this post and the book in general.

Not well organized

Probably you are right. There might be books that explain things much quicker with clearer examples. But, whenever I read a book, I forget about "time constraints". And that allows me to empathize with the author; to truly understand (as much as possible) the intent behind him saying things the way he says it. Helps me grasp things definitively. Maybe this approach helps you the next time? :)
Anyway, finally, it is up to an individual's taste and style of reading. In that, I agree with your points on organization and lack of examples. However, surprisingly, personally, I have not at all felt that in my reading so far. (I guess that is partly because I could very clearly relate to ALL the "general" problems he was talking about already.)

Irrelevant chapters

I disagree. In my experience, I have found that perspective matters, history matters -- perspective and history about how the software industry evolved. That is the reason why I -- albeit skeptical at the beginning -- enjoyed reading through all the initial chapters, especially the programming paradigms and the stories from the 40s through 60s.

As an example, I find great wisdom in the following lines from the book (paraphrasing).

The principles of good architecture have not changed since the early days of software engineering because there are no new programming paradigms discovered after the 50s.

Why I like it is because remembering this is very helpful whenever you are tempted to think that "I am dealing with such a truly unique system with all new technologies that these design principles do not apply here at all". This thinking is very common in green developers, and this book, if read with the right attitude, humbles them down and teaches them how not to reinvent wheels and rediscover fire. (Hope that made at least some sense. :P)

Architecture's intent

Architecture should clearly relay the intent/purpose/behavior of the system rather than how/on what the system is built on. (My recommendation: Read entire Part V)

This is the most valuable lesson for me (yet). So, even without clear examples, this line can help one validate the effectiveness of a system's architecture diagrams... every single time.

It is all about the business

Business rules, very strictly speaking, are rules that would make or save the business money. Critical business rules are at the highest level and do not change regardless of who performs them (human or machine or types of software). Application-specific business rules are in the next level and specific to the application that was created to carry out the business/work.

The next valuable lesson for me. Of course, the book explains it much better than I have above. But, why I wanted to mention this here was because it now gives me a fresh perspective to imagine/visualize business requirements clearly.

I can now apply this line on any incoming business requirement and imagine, "what if I had to make it happen using actual people? How would I manage all the operations? Whom will I employ? What information (read: data) will I provide to whom. Who will do the calculations? Who will go and deliver the output we produced, and in what format? How do I ensure that my business does not become dependent solely on one person (sounds familiar? Eh? eh? ;)) ? How can I effectively "extend" a part of my business to "external businesses" and that enhances my business over all (read: plugins)? And so on and so forth.

SOLID

I actually skipped SOLID (Part III) entirely because I am already convinced of their benefits. Moreover, the answers to creating (and maintaining, over time) a good architecture does not lie within SOLID alone. It is the combined knowledge of all the concepts, and application of that knowledge, and based on experience and intelligent guesses.


In summary, I guess I would recommend that developers who can spare time to read a novel should definitely read this story book. :)

 

Thanks for the thoughtful comments, Krishnan.

There are plenty of people who enjoyed this book and rated it 5 stars on Amazon so you are definitely not alone in recommending it.

Cheers.

 

Finished reading the book over the weekend. I will definitely agree with you now. More examples would have been better. :D

I also found one other thing funny. As the book says, "architecture should relay the intent/purpose of a system than what it is built on", I could not see this being applied in the Video sales example. Ha! All I saw was presenters, views, interactors, controllers, etc. divided vertically by type of actor. The diagram does say that it is "a preliminary component diagram", but I don't think anyone would have minded if the author provided "detailed component diagrams" for the next 20 pages.

Similar to what you mentioned in the post, all the background history and concepts and terminologies and philosophies finally build up to a simple "preliminary component diagram". Wait what? That... seems a bit... silly, right?

Anyway, this was a great book for me to get clear understanding of the terminologies and concepts in this domain. Next up, the Martin Fowler book you've recommended.

B)(y)

 

If you really, really, really want to understand software and system architecture find any material by Juval Löwy.

A good start is here:
youtube.com/user/IDesignIncTV/videos

I've attended his Architect Master Class last year and it blew my mind away. This class is sold out months in advance by architects all over the world. And rightly so.

His book "Programming WCF Services" tells you all the why and how behind a solid system, solid code, solid maintenance and security etc.

Juval Löwy is a real architect with the right mindset. He's been responsible for the review of .NET and WCF architecture.

Robert C. Martin is a very keen software engineer and might accomplish very good software. But he's not an architect. He has not the right mindset.

 

Thanks for this. I'll definitely check it hits videos.

 

I would like to know what you meant by that ?

I'm pretty sure a system that never violated the SOLID principles would be a giant mess.

I personally think that you cannot design a complex system and completely respect whatever principles you want to apply.
The aim for me is to have as fewest rules as possible and the correct focus depending on what you're working on.

 

Blindly following rules is bad idea and can lead to an unmaintainable system.

This post illustrates my point: dev.to/codemouse92/clean-dry-solid.... Skip down to the "When SOLID Becomes Stupidity" section if you don't want to read the whole thing.

 

That's what I meant as well.

I'll read the whole thing !
Thanks

 

I have been studying Clean Architecture for a while and are deciding to adopt it for my next projects. But, I also wanted to find any negative views about it, then came to this article. To my relief, your comments are more about the organisation of the "Clean Architecture" book itself and the way Uncle Bob presented the materials in the book, not really about the concepts of Clean Architecture. Yes, I too find the book not very easy and pleasant to read, but the underlying concepts about Clean Architecture are really excellent. You need to get more information from other sources, for example, Uncle Bob's video series or other people's writings on this topic about Clean Architecture.

 

Your review is reasonable and led to other useful resources contributed by other people, that's good. For me, I love Uncle Bob's Clean Architecture. I've read "Patterns of Enterprise Application Architecture" and kind of understood and related some patterns to my work but still need much more time to digest the context and use of other patterns. A question I've been thinking about without answers is why the authors can figure out these patterns, why they are considered as good practices. In this respect, Clean Architecture sheds a light on the principles to judge software architecture as well as design patterns. Really appreciated Uncle Bob's work.

 

This is the perfect description of that book. I've read it and I'm glad that there is someone else with the same opinion.

 

For me it was nearly the same experience. Not much that really helped but a few parts that expanded my horizon.

If you are looking for a book that gives advice on how to deal with so called legacy systems, than you should definetely read this: Working Effectively with Legacy Systems

Hopefully Uncle Bob reads most of the feedback because i think we are not alone with it!

 

Thanks for sharing, Rob.

Yes, Working Effectively with Legacy Code is an awesome book! It's not really an architecture book but it's with its weight in gold if you're working on a legacy system.

It's in my top 5 programming books of all time.

 

I agree with you that - even if it might look like that in the beginning - the book is not an easy read.

When having finished reading the book I was really motivated to see the benefits of Uncle Bob's thoughts in practice but I also felt left with many open questions on the details. So I decided to take one of my projects and convert it a "Clean Architecture" according to the presented principles.

I share my experience when "Implementing Clean Architecture" on my blog: plainionist.net/Implementing-Clean...

If you have some time reading through the series, your feedback would be highly welcome!

 

Very interesting. I took a quick look and you've written a small book there. I've bookmarked it and I'll take a look when I have some time to read it but I'm wondering if you would give us a little summary here.

Questions:

  • Did you find changing your architecture to be useful?
  • How hard was it? Was it worth the effort?
  • Did creating boundaries in your system help more than it hurt?
  • How useful was the book in helping you make your architecture decisions on a real-world system?
 

Although I haven't read the book I read a lot about clean coding principles online and, unfortunately, they also suffer of either no examples or the "CatDog" example (a.k.a. minimalistic examples).

You might be interested in the few videos I posted here about clean coding from my Youtube channel where I emphasize on actionable examples. If you have the time, I would like to know if they have the examples you were talking about.

 

I locker at the source code, i ready clean code, i crawled the entire cleancoder website and even read clean architecture and what frustrates me the most is that he keeps babbling about how clean code should Express intent, just to find out that his own code does everything but that, than in my opinion he does not have a right to judge us. I'm trying to create a framework in .net based on the items he talks about, in the sense that he intends them(which is completely correct btw) and my implementation looks very different from his. Just to make things clear I chopped my code into separate assemblies instead of separate name spaces, and when I were to do that, just like java revs do, then my implementation would still be more expressive than his. So this rather disappoints me. I truly believe that his vision is correct, just not the way he presents it as being the holy grail. As soon as I am satisfied with the result, I'll place it in a gift repo for others to judge.

 

Please post your code when it is ready. If be interested to see what you come up with.

 

I'm currently half way through.. .some I curious where my opinion will land once I'm finished. But I will make this one comment mid way through, that I feel will agree with our take.

The continual use of acronyms to reference the previously covered concepts can be hard to follow.

SAP, SDP, DIP, CRP, OCP, CPP....
Maybe they are just too similar? Maybe this vocabulary will come with more time / usage (which I tend not to get when just reading the book straight through)? Maybe they are a necessary evil?

 

Interesting point.

I don't remember the acronyms causing me problems when I read the book but I can certainly understand how they could be a problem for someone who is unfamiliar with them or for whom English isn't their native language.

Please check back when you finish the book. I'd love to hear your overall impressions.

 

I think that a book that makes you to ask yourself things, is an extraordinary book. Not always we have the answers, but having good questions is half path to knowledge.

 

People are definitely divided on this book. It's got excellent ratings on Amazon and yet lots of people, including me, find it missed the mark in a number of areas.

Cheers.

 

Your title is misleading. You don't like the book does not mean you should not recommend clean architecture.

 

It never occurred to me that the title might be confusing. Interesting feedback. Would you agree that the first paragraph makes it clear that the post is about the book, not the concept?