The first chapter sets the tone: if something were always the right answer it would already be automated and nobody would need architects. What is left is trade-off analysis, and the book teaches it on the problems with no pretty answer: when to split a system, how to divide the data, what to do when one operation touches several services and no single transaction holds it together.
What I took from it
The forces that push towards splitting and the ones that push towards keeping things together, each with its own name. Having both lists changes the conversation: instead of arguing about whether to separate a module, you walk the list and see which side weighs more in this case. Sometimes the answer is to split nothing, and that is an architectural decision too.
Data as the real problem. Splitting code is the easy part; the hard part is deciding who owns each piece of data and what happens when two sides need it at once. Since then, before proposing any integration, I draw first where the data is born and who has the right to change it.
And the discipline of writing a decision together with its cost: what is gained, what is given up, and under which condition it should be revisited. A decision without its downside written next to it is an opinion with a date on it.
What I left out
Plenty. The book reasons about distributed services at a scale a mid-sized company will never reach; the chapters on distributed workflows and contracts solve problems that appear with dozens of services. And the fictional narrative running through it, with its support team and invented meetings, takes up serious space. It got in my way; I know people who finished the book because of it. Here is the part of this I deliver.