Granularity and coupling in microservices – Data Architecture: The Hard Parts

All software architecture involves trade offs. But traditional analysis tools don’t work well for today’s distributed systems.

Software Architecture: The Hard Parts 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.

[MsBilalislam]

thanks a lot for everyone for really useful information about to todays and future of programming.

[nexus]

I’m tired of hearing the categorisation of engineers and architects as two distinct personas. Can we stop this one day as it tend to lead towards a bias towards one of the other has to be more correct for some design aspects. As many other architects I started as an engineer but I was opinionated about how we should implement our software that I was made an architect so I could spend more time on design compared to coding. Can we simply agree that software is one of many lenses over software and tends to get given to people who does this as their main work. I don’t want to sound rude but in my view the average engineer often don’t have the time or interest in the bigger picture and complexity of design across entire tech stacks horizontally and vertically that spans multiple systems. Give the job of an architect to the engineer and see how much time they have left to do their implementation at a high quality catering for all the proper lower level design, testing, project structures, configurations, etc.