[Book Review] <Get Your Hands Dirty on Clean Architecture> by Tom Hombergs
Published: 2023-06-10 13:51:16

# TL; DR
This book is about how to implement the [hexagonal design pattern](https://en.wikipedia.org/wiki/Hexagonal_architecture_(software)) for a (web)backend system.

- Good Parts:
 - Re-explaining the SOLID principles very practically
 - Detailed explanations with Java(Spring) code examples
 - Well organized chapters from the beginning to the end
- Soso Parts:
 - Assuming that reader understands how Java(Spring) and its ecosystem work, so might as well be difficult to read for those who doesn’t
 - Only covering a simple example: what if the service gets bigger, or what about interactions between use cases?


## Why did I choose this book?

As I have become familiar with backend services from various materials(books, work environment, etc.), my interest in writing testable and easily-modifiable code also has grown. As you know, there are relentless demands for new features, bug fixes, and changes in the existing features in the service code. Thus, developers should write their code in a way such that it is always ready to change with minimal cost. 

Then there was this word popping in my head: hexagonal architecture. I have known this word for a long time, but never have tried to implement it myself: maybe because I wasn’t very interested in web technologies or thought that classical MVP layered architectures were sufficient. However, now that I am serious about how to write good service code, this hexagonal pattern and the domain-driven design(DDD) philosophy behind it were very attractive to me.

This is when I found this book, [Get Your Hands Dirty on Clean Architecture](https://www.amazon.com/Hands-Dirty-Clean-Architecture-hands-ebook/dp/B07YFS3DNF) by Tom Hombergs. It was not a huge book, and there were code examples that are easy to follow while practicing with my own code(and there are not many books particularly about this pattern either). So it was natural to begin with this book for understanding the hexagonal pattern.

## Good parts

### 1. Re-explaining the SOLID principles practically

For me, the SOLID principles had been still a bit of mystery. Every time I tried  to understand them, most of the materials on the internet were either with too simple examples or fairly abstract to grasp. However, the book explains the SOLID concepts connecting to somewhat “wrong” architecture patterns, so that readers now can understand what the purposes of these principles are. 

### 2. explanations with Java(Spring) code examples close to real-life services

Although some parts of them are not explicitly specified, the code examples don’t look like contrived(no `foo` or `bar`). With realistic bank account examples, readers can relate the explanation from the book to their own projects, and could consider the ways to improve the codebases. 

### 3. Well organized chapters from the beginning to the end

This is my favorite feature of this book. It starts with a general introduction to the concept of the hexagonal architecture and its purpose, and continues explanations on the architecture part by part, such that it is easy to follow while practicing with my own code. Since I personally use FastAPI for backend development, I translated the Java code in the book to my own Python code. It was way faster to understand the contents when I was actually typing my own code. 

However, there are also a few points that I felt could have been better, if written in different ways:

## Soso parts

### 1. Assuming that reader understands how Java(Spring) and its ecosystem work

Although it is completely upto the author’s choice, but I personally think the Java examples are too “Java”.  Imagine you’re a Python or Golang developer not heavily using the OOP concepts and techniques: then it might be that this book is not easy to understand. Moreover, the parts where the author explicitly uses Spring features are almost impossible to grasp what those codeline means; I had to Google every time I read those parts.

### 2. Only covering a simple use-case example

As I was developing my own project using this hexagonal pattern, I was wondering what if there are interactions between use cases, or a use case gets too many features so it is no longer a “single” use case. Throughout the book, there is only a single use case for the demonstration of the main concepts. How about other infrastructures being connected to dedicated adapters such as cache layers, load balancers, or message queues? I wish the user would cover those more enterprise-related cases as well in the future.

## Conclusion

But still, I think the book is quite decent in explaining the core concepts of the hexagonal architecture in very structured way(there are a number of materials on the Internet that makes this topic more confusing). If you’re a Java developer, it is highly recommendable (maybe you could finish the book in a single day). However, even if you’re not a Java developer, it is worth trying. I learned a lot from this book.