Software Architecture: The Hard Parts

Chapter 11. Managing Distributed Workflows

Tuesday, February 15, 14:34

Austen bolted into Logan’s office just after lunch. “I’ve been looking at the new architecture designs, and I want to help out. Do you need me to write up some ADRs or help with some spikes? I’d be happy to write up the ADR that states that we’re only going to use choreography in the new architecture to keep things decoupled.”

“Whoa, there, you maniac,” said Logan. “Where did you hear that? What gives you that impression?”

“Well, I’ve been reading a lot about microservices, and everyone’s advice seems to be to keep things highly decoupled. When I look at the patterns for communication, it seems that choreography is the most decoupled, so we should always use it, right?”

"Always is a tricky term in software architecture. I had a mentor who had a memorable perspective on this, who always said, Never use absolutes when talking about architecture, except when talking about absolutes. In other words, never say never. I can’t think of many decisions in architecture where always or never applies.”

“OK,” said Austen. “So how do architects decide between the different communication patterns?”

As part of our ongoing analysis of the trade-offs associated with modern distributed architectures, we reach the dynamic part of quantum coupling, realizing many of the patterns we described and named in Chapter 2. In fact, even our named patterns only touch on the many permutations possible with modern architectures. Thus, ...