It’s been a while since I blogged about anything, work has been pretty challenging and I’m doing my best to keep up. Which, by the way, is a great thing.
On September 15th I received a notification email saying my Clean Architecture book pre-order was now fulfilled and I could download the book. I was very, very excited that it was finally released. I had been waiting for years and it kept getting delayed. By the end of the day, I had read 30% of it and only stopped because it was way past my sleeping point.
Part 1 to 3
Set the ground to being the architectural discussion. They do a great job of explaining the different kinds of programming and offer a different view of the SOLID principles. Even if you know SOLID, I’m sure there’s a thing or two to learn from those chapters.
After this, I confess I started rushing a little bit, I couldn’t wait to get to the Case Study chapter which is near the end of the book.
Talks about the component principles. I wasn’t surprised to see this in the book as it offers valid advice on how to break down components in a way that allows teams to work independently. If you ever wondered how to apply SRP to a component level, the chapters in this part will explain it in a very nice pace.
Talks solely about architecture. From top to bottom, left to right. It begins at the very beginning explaining what software architecture is and what is not. It does an incredibly good job at explaining what high-level policies and low-level details are and how you want them to connect. This is the part of the book that I believe is a must read for any programmer. It as necessary as the Clean Code book as a whole.
Is where most people will probably disagree with the author. I, however, do not. Every chapter presents a case to make the point that things such as the Web or databases are just details. If I read this 6 years ago I would strongly disagree with that point of view, but experience has shown that what truly matters are the high-level policies, the business rules. How you store or display that is less important than what the system is supposed to do.
The other half of part 6, specifically chapter 33 was the most anticipated chapter for me. At this point a week had passed since I began reading the book and I recall reading it entirely as fast as I could and for the first time, I was ( as much as it bothers me to say it ) disappointed. I was actually frustrated. I waited for years for that single chapter, where I’d see the concrete implementation of the Clean Architecture and it just wasn’t there, at all. In my imagination, topics such as entity design would be there, such as:
How DDD fits into the Clean Architecture’s idea of an entity. Multiple interactors vs sub interactors.
Multiple interactors vs sub interactors.
How to create async interactors.
The list goes on…
Is basically Uncle Bob’s biography in terms of systems and architectures he’s been part of, just as a good as the previous chapters. It made me feel as I was reading the Clean Coder for the third time, which was a great feeling!
The guidelines in the book are golden. It certainly had shades of Clean Code where I felt excitement over what I was learning.
At the time of this writing, most of my frustration went away, actually. I think the things I’m still uncertain about are up to me to discover. Every system is different and brings value in its own way. It’s just a matter of what works for that particular system.
That’s a 5-star book for me. If you haven’t read it yet, go pick it up; you won’t regret it.