Clean Architecture failed to meet my expectations on a number of fronts. Despite Mr. Martin's obvious passion for the topic, Clean Architecture is ...
For further actions, you may consider blocking this person and/or reporting abuse
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.
This sounds like a great beginning for a movie about the rise of AI programming. :D
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:
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 !
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.
I m pretty happy he didn't provide any concrete example because everyone despite of tech stack can grab the idea and implement it.
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.
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.
Holy true. I've nothing to add. I think the same.
True again. There is only one chapter which describes the example location of components across multiple libraries, but it concerns newly created projects.
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.
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.
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.
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.
Admittedly, some people don't learn well this way.
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.
And may I just assert why he holds something like SOLID as hard rules?
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.
or
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.
From the foreword, Kevlin encapsulates this idea:
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.
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:
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.
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:
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.
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.
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.
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 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.
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.
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.
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?
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.
First of all, thanks for sharing this thorough review of Clean Architecture. So, I see that you mentioned about Patterns of Enterprise Application Architecture and how applicable the patterns described are on your systems. Although post is from 2018 I also see some comments mentioning the same (comments from 2020).
In case you work with Java and use some of the mainstream frameworks (I know it's a details but in real life we still use them). My question is how did you manage to find the patterns from PEAA applicable today? I ask this because most of the patterns described are available and implemented by a plethora of frameworks and libraries. Just one example that comes to my mind here: Data Mapper. We have Hibernate which is very close to Data Mapper.
PS: This is a very honest question, because I'd like to give PEAA a new chance. From my perspective, today this book is good as a History book for people to understand what underpins the current libraries and frameworks highly used.
Sorry, I missed your reply. Dev.to usually sends me an email but something happened and I didn't get/see it.
First, it's entirely possible that PEAA might not be useful for you. If you architecture is dictated to you by your framework or tech lead or the shape of your existing code base, there might be little value in reading it. The book is also focused on business systems so if you are doing embedded or systems programming, etc., it's probably not the book for you.
I work primarily on legacy business systems running on the web and that's definitely PEAA's target. So PEAA offers advice on layering, web presentation patterns, several patterns for interacting with your database, session management patterns, patterns for isolating your domain logic, many, many tips for evolving the architecture of an existing system, and many other things I hoped to see addressed in Clean Architecture.
I think the larger context you might have missed is that only about 10-15% of programming effort is directed towards new projects. The vast majority of effort is directed maintaining and extending existing systems. Many of those systems are > 10 years old and may contain architectural anti-patterns or little architecture at all.
Cheers.
Hey Blane.
I totally agree with you.
I read the book and didn’t get the Martin’s point.
My intention was learn about clean architecture, but the book presents other points.
Here in Brazil, the people loves Martin and his book, but I think this book could be better.
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.
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.)
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 agree. We could benefit from more scientific research about what works and what doesn't in software development. Thanks for your comment.
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).
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
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
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)
I would like to know what you meant by that ?
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 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.
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:
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 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.
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?
It is good to read this review... I thought it was just me.
I would be glad if you ever write an architecture book that fixes the issues pointed in this article.
Its true Clean Architecture is a tough read. I tried reading it last month but just couldn't finish it. I expected more from Uncle Bob
Thanks for the heads up. This book was on my reading list, but now I will give Patterns of Enterprise Application Architecture a try :-)
A 'dislike" for your post.
I found your post was picky. "Clean Architecture" is an excellent book for me, we should read it with a hindsight of our experience and past projects to appreciate it as it is. Yes, it can add more examples, more demonstrations as you demanded but then it would be bulky rather than handy as a handbook format. There could be various reasons they chose not write the book as you like.
Reasonable people can disagree about these things. The book has a 4.6/5 on Amazon.com so you are in the majority, but I stand by everything I wrote.
Thanks for taking the time to reply.
Did you just say that Java is brittle compared to modern JavaScript?
Me? No. The "brittleness" of a language is dependent on the person using is.
I'm a big fan of his work but I agree that there were not as many big takeaways as I would have liked. Perhaps it's because I watched so many of his talks on youtube and there was a lot of repeated lessons.
This talk on SOLID Principles covers one of my favorite takeaways from the book: the importance of inverting dependencies. He talks about it being the biggest strength of OOP and crucial for creating good architecture.
youtube.com/watch?v=TMuno5RZNeE
I do think those with an OOP focus would enjoy his talks and books more. He tends to focus on programming in C and java.
I've enjoyed his talks on YouTube as well. I was expecting the book to go into more detail instead of basically taking the same content he covers in a 45 minute talk and turning it into a 375 page book.
Thank you for this post, I can appreciate reading your insight prior to reading through Clean Architecture. I've come away with two better reading alternatives reading the comments!
Creating software systems is an art.
No one knows exactly how programs are written.
If you do not understand what Martin writes, then your time has not come yet.
I really don't think that's my problem but thanks for taking the time to leave a comment all the same.
Let's wait for his next book: "Clean architecture by example" ! :)
Quite ignorant