Software Architecture: The Hard Parts: Modern Trade-Off Analyses for Distributed Architectures

This is a great book! It is a sequel to the authors' prior book, "Fundamentals of Software Architecture" (which isn't a prerequisite to this book, but is helpful). I liked that book. This one is way better.Where the first book stayed fairly high level and abstract, and focused on working as an architect in a company, this book is all about actual tough architecture decisions in practice. It applies some of the the first book's approaches and patterns (and a whole bunch of new ones) towards a fictional example application which a dev team is tasked to completely refactor.Basically, the book is structured as a narrative about a team breaking down a faulty outdated monolithic application into a modern microservices-based architecture. Each chapter essentially compares different aspects of how a monolithic architecture might have been written to do something in the past, then how a modern microservice architecture could do the same thing today.Along the way the authors offer terrific advice and approaches for effective tradeoff analysis (and countless suggestions and tips) that you can use when refactoring a large monolith app (or when building microservices from scratch), detailing at every level how you might sort out a tangled mess of dependencies into a clean microservices stack - from shared code libs/components/modules, to shared database tables and schemas, to various network concerns, etc.There is nearly no code (it's not an implementation book), but the descriptions of each example scenario, pattern, diagram, and everything around it are extensive and detailed. The authors don't actually offer any definitive "best practice" in any of the scenarios they consider, but rather present all the pros and cons of each approach you might consider - which all together support their overall thesis that there are no right or wrong answers in architecture, only tradeoffs to weigh and consider for any given design challenge and possible architectural solution.I give this book my highest recommendation - it's a winner.

This is a great read for those directly or indirectly involved in software architecture.The book covers basics , patterns, and a few more advanced topics and makes for a great reference read thanks to these sensible advice provided.I originally purchased this as an audio book but repurchased as a physical copy due to its quality.

The first part of the book describes strategies on how to break apart a monolithic software package into components. The second part gives advise how to make those separated components work together.In doing so, the authors acknowledge that there is no such thing as “best practice” in how to design a system since every organisation has their own requirements and existing baggage to deal with. Designing a system fit for purpose is unique and hard. The book presents different options how to tackle most common problems and the associated trade-offs (e.g. data consistency vs. responsiveness).The red line throughout this book is a fictitious company where the IT department needs to re-architect the existing system. Each chapter starts with a discussion (i.e., meeting) of the problems that needs to be tackled. Then, the theoretical aspects are described. At the end of the chapter, the team makes a decision which seem to be appropriate for their specific situations based on trade-off analysis discussed in the theoretical part.This makes the book a very useful as one gets a pretty comprehensive understanding of various methodologies as well as possible practical applications.

Lots of books about architecture can give you a focus on a particular technique, or a technology. But this is one of the few I’ve found which captures a realistic scenario across an entire system, which is often where most of us face the greatest challenge.Nothing presented in the book is done in absolute terms, the rough edges are laid out, and wide varieties of technology categories are included.I’d call this a must read for anyone looking to architect a distributed system, or who are looking to handle a debt ridden system in general, to find the mindset and practices needed to support it.

The real jewel of the book is not its well presented categorization of distributed communication patterns, but its repeated highlighting at that architecture decisions are all about trade-off.It won't solve the challenge straight away, yet the learnt analyzing technique and mindset set me on a right path.

Great book. Just what is promised in the title: practical walkthrough of trade-off analysis for the forces in play when building distributed systems. The authors also collect/define terminology that makes the articulation of these complex problems straightforward which gives engineers and architects the ability to manage trade off with both technical and business stakeholders.

The media could not be loaded. Fast delivery, Book Quality is top notch.

An excellent follow up to the fundamentals of software architecture. This book describes an easily understood framework for making decisions. The mixture of diagrams, scenarios and theory is very useful.

The book is ok, is a softcover book but the material is ok, I give 3 stars because of the packaging is very poor with kraft paper and plastic, my book arrived with some minor damages. I think a box would be ideal for this book.

Caminhos certos, mas cada um com suas consequências e "trade-off's" específicos. O desafio de decidir por uma abordagem de arquitetura para suportar uma operação de negócios é apresentada de forma bastante interessante. Baseada num cenário verossímil, e muito comum nas empresas. Vale a leitura.

Awesome book. Great overview and some deep dives into the many trade off dimensions architects are challenged with every day

This is a great book. I enjoyed it far more than the fundamentals book. If you can master Kleppmann for the infrastructure grounding and this for real life use cases you'll be well on your way. I really appreciated the fact that they point out tradeoffs *everywhere*. That's part of the job and it can be hard to see them when we gravitate toward one option because it feels right or because of groupthink.Some minor criticisms:* the Data Mesh chapter felt tacked on, underdeveloped and in some places was incorrect or at least confusing (e.g. it says data warehouses cause loss of domain partitioning which is not true)* The book talked about tradeoffs so much it wasn't always clear why they thought taking a certain path would hurt a certain quality attribute. "Because there is more coupling scalability will suffer", etc. Perhaps. But explaining how would be great. The book hints at some relationships between quality attributes. If that were more well-developed that could be a way to better understand these statements too.* While I'm sure it wasn't meant for effect, there is only one woman in the story portions, she is somewhat naive, a bossy PITA and has to be dragged along most of the time. Having the *only woman* play that role stood out to me as potentially insensitive.

Very good. Yes