Book review: Clean Architecture
I've recently read the Clean Architecture book and I share my impressions with you and in which aspects I see it useful
Yes, reading books is also an important responsibility of the Software Engineers and Tech Leads. Lately, I prefer to read them on paper.
This is the first issue I dedicate to share with you my impressions about a technical book I read; I would love you could give me feedback if this is something you would like to get more. Now, let’s jump into the topic.
I’ve read the Clean Architecture book, by Robert C. Martin, and in today’s issue, I cover
Overview of the book.
For which professional profile do I consider this book important?
The takeaways.
The book starts with a revisit of some concepts that, you, as a Software Engineer, have been told at some point. All the SOLID principles as reviewed in the initial chapters (Parts I, II, & III) and also some important mentions, like functional programming, structured programming, and object-oriented programming with concepts like polymorphism. It emphasizes the Dependency Inversion Principle, which proposes that the dependencies must point out from inside to outside, from the most internal layers to the most external layers of your code, allowing flexibility to maintain good maintenance of your code. If you have a more senior profile, you will know all this, but in my opinion is healthy to revisit the ideas.
Later, in Part IV of the book, my favorite section begins. It introduces concepts and ideas on how to decouple your code. Part V is big and continues in the same way as Part IV but delves into more detail. Chapter 22, titled 'The Clean Architecture,' stands out as my favorite from the whole book. It introduces the concept of hexagonal architecture, emphasizes the importance of decoupling code, and reiterates how dependencies should be organized “from outside to inside”, with the “inside” representing your domain and the “outside” representing the details—all managed through interfaces.
Even though it is the last one, Part VI is no less interesting. While it's true that the main ideas were developed in the previous chapters, here the author shares some important insights about what "details" means and reasons why decisions about them, such as choosing the database technology, can be postponed for later.
I see this book as an important one to read for any level of Software Engineer since addresses the basics of software architecture and some topics more sophisticated and which would be useful when you play with complex projects. I would recommend this book for you, as a Tech Lead, and also for the Software Engineers you may be responsible for in terms of technical growth in their careers.
The takeaways I found interesting to share:
Work in your domain. Your code should “scream” what the application will do.
Use interfaces and specific DTOs to move information across different layers.
Postpone the decisions about details to the end of your implementation.
As I said at the begining, this is the first issue I dedicate to sharing with you my impressions about a technical book I read; Do you find it useful? I would love you could give me feedback if this is something you would like to get more of. Drop me a comment or reply back this email!
Best,
Marcos.
Links