What Book?

I recently started on a new software development position, and was immediately faced with an unexpected architectural choices - the team used something called "Hexagonal Architecture" which was new to me.

So I was suggested (among other materials) to read the "Get Your Hands Dirty on Clean Architecture" book by Tom Hombergs.

General Impression

The gist of the idea could be simplified as "Dependency Inversion Everywhere" - meaning it heavily abstracts everything to interfaces/abstract clasees: abstractions between API and business logic, abstractions between database ("persistent layer") and business logic, abstractions between any external dependency and anything that uses it.

The book heavily advocated for using this architecture, emphasizing that clear structure and abstractions galore would mean any changes would be isolated to a specific area and would not require changing other places, such as replacing one DB with another or changing DB storage structure would not require changes anywhere else.

To me (especially after few weeks working with a system designed over these principles) this all sounds nice but comes with a steep price: build all the abstractions is a lot of extra work, and implementing adapters between layers is a lot of tedious boilerplate-creation work, because it's mostly same-fields-to-same-fields, with maybe a few naming or type differences, but it all has to be clearly typed. And then the most common changes, such as adding new field to the data structure, would still require changes in ALL places, including several sets of tests implemented to test each side of abstraction.

So to me, it's an extremist approach to the software architecture - structure is good, but too much structure means a sacrifice in velocity and fun, because following all the guidelines and rigid structure requirements is slow and sucks fun out of creation.

Additionally, even though the author tries to point out that it's not the only way to create things, he immediately emphasises the benefits of this specific approach, which comes as a somewhat unbalanced opinion.

Conclusion

I think it's an interesting read to understand another perspective and get familiar with ideas being used in software architecture today. I don't necessarily agree with those ideas, or like the delivery - but some of the thoughts are valid, and reasonable usage of the dependency inversion is a useful practice.

That said, it's good to understand and use the principles, but it's equally good to disregard them if the price is high but benefits are dubious - clear naming of classes and variables, comments at puzzling places and some structure in the code IMO brings 80% of the maintainability, with the rest being heavily opinionated and costly in learning for insignificant benefits.

This might differ in larger scale though, when structural rigidity with component exchange flexibility means multiple teams could collaborate without causing each other troubles - but it contradicts the idea of service-oriented architecture, when we're dividing responsibilities to a stand-alone services, and I like that approach much better (see my "Building Microservices" book review).