Book Review: Fundamentals of Software Architecture
I hate-read my way through this book. I have no idea who its target audience actually is. It's so high level and devoid of actual explorations of engineering approaches that it feels like its only true purpose for existing is as a clout vehicle for the authors. It's easier to sell those training seats if you've literally "wrote the book" on architecture[0], I guess.
The problems with this book:
It's filled with dubious content and claims
So many of its statements are just downright nonsensical or overly broad to the point of uselessness.
Layered architectures don’t support fault tolerance due to monolithic deployments and the lack of architectural modularity.
This is firmly in not even wrong territory. It's Exhibit A for the type of argument that goes on throughout the book. Set up some bizarre connection between two ideas, and then make even more bizarre assertions about their "capabilities".
Someone who learned everything they know about system design from this book will be absolutely gobsmacked when they later discover that availability zones exist, that even the humble monolith can be deployed across them, and that it's one of the core selling points of all this "cloud" mumbo-jumbo.
These bizarre opinions and bad takes extend to every part of their Architecture Rating System. Layered architecture? That thing where your entire application is so basic it all fits into a single blob? 1/5 stars for testability. Meanwhile, micro-services? 5/5 testability. No hard problems there!
Just to further drive home this weird pattern of creating a loose connection and then making strong "wtf" level assertions, you've got this puzzler:
Event storming as a component discovery technique comes from domain-driven design (DDD) and shares popularity with microservices, also heavily influenced by DDD. In event storming, the architect assumes the project will use messages and/or events to communicate between the various components
Now, DDD has the same problem as agile: it's a decent idea that's since been overtaken with talentless consultant hacks for whom the process and ceremony itself is the end goal[1]. So, I hate to even approach a "no true Scotsman" level defense for one of its ideas, but, I'm preeeeeeeetty sure that Event Storming, i.e. that process of "figure out more or less what the major business events are", doesn't actually require any kind of prior decision about how the software architecture will work[2]. That'd be pretty brutal constraint if it were the case – "Listen, we'd love to hear more about the major events in your business by using these orange sticky notes, but we've already decided that we're not going to use messaging in our architecture, so............"
It's superficial to the point of being worthless
The reason the book can be so free with its bizarre assertions, is that it makes them entirely in passing, and at levels disconnected from reality. Despite being self-described as "an engineering approach," it never dips low enough below the surface to explore any of the consequences of its individual architectural decisions or "trade offs" (as it so superficially champions throughout the book). Anything can be broadly correct or hand-waved away when you're drawing at 10,000ft and using a fat magic marker. "Layered architectures don't have fault tolerance" sounds vaguely reasonable so long as you don't think about the actual engineering and what kind of deployment conditions would make that true.
The mighty – and separate! – E N T E R P R I S E Architect role
One of the most obnoxious things about the book is how much time it devotes to maintaining the "other" status of the mighty Software Architect[0] and their oh-so-important role in software architecture.
This type of hierarchical, ladder hoisting bullshit fills me with contempt. Roles don't matter. Levels don't exist. There is no spoon. If you're a software developer, a fundamental part of your job is defining the system architecture – and questioning existing architecture. How good you'll be at this is a function of time. There's only one way to get better, and it's not by waiting for the formal hierarchy to grace you with opportunity from on high. Too many people let this role/level type of thinking turn their brains to mush and get stuck or pigeonholed as a result.
Tl;DR: didn't care for it.
Footnotes