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?
He compiled them (over years, talking with colleges)
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
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.
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.
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.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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:
Please share with the group if you can. I'd love to see what that looks like when it's done well.
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.
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.