Software Architecture: The Hard Parts
Software Architecture: The Hard Parts book is the follow-up book after the Fundamentals of Software Architecture book. This new book is all about software architecture trade-offs.
These trade-offs are in many different aspects of the architecture; service identification, service communication, data ownership, data consistency, databases, distributed transactions, transactional sagas, service contracts. They spotlessly explain these trade-offs, and I like their clean approach. To select a solution after evaluating these trade-offs, we need a context. They created this context with a company’s fake microservices architecture migration project (it is very realistic, by the way). They show how architects decide by using these trade-offs in their context.
The book is also a reference book to use when you encounter these problems in your context.
Everything depends on your context in software architecture; someone’s terrible solution can be your suitable solution, and it’s very typical. When deciding your systems’ architecture, being over-ambitious to other companies’ solutions without thinking much about your context is a trap. I have fallen into this trap before. If you hear the state-of-the-art solution keyword in a discussion, it might mean that you’re close to that trap because there is no state-of-the-art solution or best solution in software architecture.
There is no single development, in either technology or management technique, which by itself promises even one order of magnitude [tenfold] improvement within a decade in productivity, in reliability, in simplicity. —–Fred Brooks from “No Silver Bullet”
“Don’t try to find the best design in software architecture; instead, strive for the least worst combination of trade-offs.”
So, know your existing context well and evaluate trade-offs according to these facts.
“The second law of software architecture; why is more important than how.”
The book perfectly showed that we could solve complex architectural problems easier if we decompose them and extract the pros/cons in a very systematic and collaborative way.
Another two good things are ADR(Architecture Decision Records) and architectural fitness functions. They use ADRs for each decision to document their context, trade-offs, and conclusion for future use. They use architectural fitness functions for auto validation of architectural choices. I tried to use ADR in our last project, but I couldn’t keep it up to date after one point. I have not used architectural fitness functions yet.
Is there anything that I don’t like about the book? Not so many things; I lost in the chapter of the transactional saga, maybe because there are many; I couldn’t align what they mean with sidecar/service-mesh; I am still very confused about data meshes :).