Software Architecture: The Hard Parts
Neal Ford, Mark Richards, Pramod Sadalage and Zhamak Dehghani
All software architecture involves trade offs. But traditional analysis tools don’t work well for today’s distributed systems.
This book provides techniques to help you discover and weigh the trade-offs as you confront the issues you face as an architect. It investigates why architecture is so difficult and provides proven mechanisms to address these complex problems and make them understandable. Co-authors Neal Ford, Mark Richards, Pramod Sadalage, and Zhamak Dehghani examine everything from how to determine service granularity, manage workflows and orchestration, manage and decouple contracts, and manage distributed transactions to how to optimize operational characteristics, such as scalability, elasticity, and performance.
This book is not just for software architects — data architects, DBAs, product managers and others will glean valuable insights into some of the complex issues architects face every day.
Architecture is full of hard parts; by tracing the common reasons and applying lessons more universally, we can make it softer.
Listen on these platforms
Following on from our earlier episode on the Software Architecture: the hard parts, we’re joined by the other two co-authors of that book to explore issues around data architecture and how that fits into these broader concepts of architecture. We discuss how it is that what looks like a software decision is frequently influenced by data.
In today’s modern distributed systems are by their very nature complex. The decisions you need to make — around the wiring of your services, what size should the services be, and how should they call one another — are uniquely complex. In Software Architecture: the hard parts, the authors explore the rough edges of software architecture and look at how you can effectively do trade analyses that work for you. We catch up with two of the book’s co-authors.
Read a free chapter
One of the difficult problems in modern architectures such as microservice is deciding what size to make the services — in other words, what is the appropriate granularity of services? Make your services too ‘micro’ and you risk creating a host of problems: communication overhead, transactional behavior, coordination and the like. Build your services too large, and you’ll miss out on many of microservices’ benefits.
This chapter suggests guidelines for teams that enable them to iterate towards the appropriate level of service granularity for their set of trade-offs. In so doing, it illustrates the types of trade offs that are common in those hard architectural decisions.