Book Review: Fundamentals of Software Architecture
Published: 2022-09-10
Update 2024-10-14: I've replaced my original review with what is here now. The original one was quickly written and weirdly aggressive (complete with Reddit commenter style righteous indignation). The below attempts to be more constructive.
The first half of the book is pretty good. It stresses that engineering is contextual and full of tradeoffs. That's great, because developing complex software is hard. But things go wrong as soon as it begins covering architectural patterns. The book forgets all of its wonderful early advice and instead slips into sweeping generalizations and overly prescriptive claims.
Often these claim become so disconnected that they're tough to even gauge as meaningful engineering statements. Take this one:
Layered architectures don’t support fault tolerance due to monolithic deployments and the lack of architectural modularity.
It sounds vaguely reasonable as long as you don't pause to think about the engineering and what kind of deployment conditions would make any of those individual statements true. ("What kind of faults aren't we tolerating???")
The reason the book can be so free with its assertions is that it makes them entirely in passing at levels disconnected from reality. Despite being self-described as "an engineering approach," it never dips far enough below the surface to explore any of the consequences of its individual architectural decisions. Anything can be broadly correct when you're drawing boxes at 10,000ft with a fat marker.
These sweeping statements get worse as the book goes on. The writing towards the later chapters becomes sloppy to the point where I'm not even sure it conveys what the authors intended. It dips into "wtf" territory with statements like this.
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
What?
DDD is a great idea that has unfortunately been overrun with talentless consultant hacks for whom The Process 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 pretty sure that Event Storming, i.e. "ask the business what it does", doesn't actually require any kind of prior decision about how the software architecture will work[2]. That would be silly 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 our architect already decided that we're not going to use messaging in our architecture, so..........."
The mighty – and separate! – E N T E R P R I S E Architect role
Personal bias, but I was consistently annoyed by how much time the book 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 nonsense fills me with contempt. Roles don't matter. Levels don't exist. There is no spoon. There is no shortage of people with fancy titles that aren't any good at their jobs. 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