Software Architecture: The Hard Parts Previous | Books | Film | Index | 日本語 | Training | Next

10 May 2024

Tweet

Software Architecture: The Hard Parts has four authors and is a tour-de-force in presenting different perspectives. They have a maxim that "everything is a trade-off" and masterfully demonstrate this perspective throughout the book. They start off asking "What happens when there are no best practices?". The first half of the book goes over the justifications for pulling things apart and the second half the reasons to put things together. Throughout the book there is the running story of a fictional team that applies the principles from each chapter to give the reader an anecdote.

They begin talking about pulling things apart by defining an architecture quantum: an independently deployable artifact with high functional cohesion, high static coupling, and synchronous dynamic coupling. Understanding what they quanta are in a system is the first step to seeing if decomposition is justified. Next they discuss architectural modularity and its drivers, maintainability, testability, deployability, scalability, availability and fault tolerance. Once again, everything is a trade-off and business needs often dictate priorities. Of course, once a decision for decomposition is made, then one must look into the feasibility. Assuming it can be done, the book talks about two methods: component-based decomposition and tactical forking and the trade-offs between them. This follows with a deeper dive into some component-based decomposition patterns:

• Identify and size components pattern
• Gather common domain components pattern
• Flatten components pattern
• Determine component dependencies pattern
• Create component domains pattern
• Create domain services pattern

Not only code, but also data must be pulled apart. The authors next discuss the data disintegrators, change control, connection management, scalability, fault tolerance, architectural quanta and database type optimization, as well as the data integrators, data relationships and database transactions. This is followed by a guide to applying these trade-offs when decomposing a database. Then the authors discuss reasons to select various database types.

Finally there is a discussion of service granularity again with disintegrators (service scope and function, code volatility, scalability and throughput, fault tolerance, security, extensibility) and integrators (database transactions, workflow and choreography, shared code, data relationships). Again they analyze the trades in deciding what's more important in a particular system.

The second half of the book begins with a discussion of reuse patterns: code replication, shared libraries, shared services, sidecars and service mesh. The value trade-offs between the different patterns are then compared. Therefollows the important topic of data, where data ownership, distributed transactions and distributed data access all play important roles in deciding what should be combined together in a particular system. Next the book compares orchestrated versus choreographed workflow and the pros and cons of each. The authors then put it all together and look at transactional saga patterns on three axes: communication (synchronous vs asynchronous), consistency (atomic vs eventual) and coordination (orchestrated vs choreographed). Those sagas are

The witty names are intended to indicate the authors' opinions of particular patterns as well as be descriptive. As always, there are trade-offs between them. Next the book discusses loose versus strict contracts and, again, the trade-offs involved. Finally, before wrapping up, the problem of analytic data is rather unusually presented as a solved problem. The data mesh is their answer, but they do spend time explaining why the data warehouse and the data lake are not as good.

Reading this book made me much more confident about my ability to analyze architectural trade-offs and I would highly recommend it to anyone needing to make such decisions.