Balancing Coupling in Software Design: Universal Design Principles for Architecting Modular Software Systems

Vaughn Vernon Signature Book

by Vladik Khononov

Microservices become immensely popular because it promised to help organizations build loosely-coupled systems that allow for fast, easy change. But microservices systems haven't always kept that promise. This book identifies the deeper problem -- how software architects and designers approach coupling - and introduces an important new approach for creating more successful designs whether you use microservices or not.

Instead of blindly avoiding coupling, leading software architecture expert Vladik (Vlad) Khononov proposes a novel method that transforms it into a powerful design tool: "balanced multi-dimensional coupling." Khononov begins by surveying existing methods of evaluating coupling, and illuminating their strengths and limitations in the context of modern distributed systems. Next, he introduces a new multi-dimensional coupling model, and demonstrates how to harness it to build modular software.

Instead of focusing solely on a single approach, Balancing Coupling in Software Design illuminates underlying design principles that are ubiquitous in SOA, microservices, DDD, design patterns, and other paradigms, revealing how each of them can fail if thoughtful design principles for coupling are neglected -- and how balanced coupling can make all of them work more effectively.

Genres: Technology, Architecture, Programming, Software, Computer Science, Nonfiction

320 pages, Paperback

Published September 28, 2024

Reviews

[Sebastian Gebski]

There will be no start rating. I was really struggling with that, as there are many positives, but they are seriously undermined by severe defects/deficiencies.

Let's start with pros:
- coupling, the book dedicated to coupling precisely!
- it's DDD influenced, but not pure DDD zealotry
- there's a clear chain-of-thought and a method applied, not some random mumbo-jumbo
- there's actually a decent intro to several concepts that really help in grasping the concept of coupling, kudos for "setting the context" properly - it's essential to build a proper mental model of coupling
- the author doesn't fall into "inventors" mode to re-create everything from scratch, there are actually many good industry references as inspirations (e.g., basic coupling types come even with historical sources of their names - sometimes unobvious today)

What about cons then?
- the way the author applies connascence (as an alternative way to see coupling) is not phrased in a helpful way - IMHO rather makes things foggy than more comprehensible; I believe it'd be better (for the clarity of this important term) to treat it as a bridge between coupling and cohesion (measure of the strength of the associations, regardless of whether it happens within or outside the module boundaries)
- at some point the author gets too lost in his own terminology or rather its duplications ;/ e.g., I still (after re-reading corresponding sections) struggle to understand how "intrusive coupling" differs from "content coupling" ... keep things simple, that didn't add value ...
- many considerations (e.g., on the "strength" of coupling are good), even if not necessarily fully practical, but once the author moved to the "distance" ... the whole chapter 8 is so off that I sat there jaw dropped. Distance is not only not defined in a clear, practical way that corresponds with real life observations. In fact, it ignores several natural considerations e.g., related to nesting (smaller "modules" talking to each other directly, but exposing some "joint" interface to the modules outside)
- IMHO there's no way to discuss coupling properly w/o promise theory, which is barely touched here ("deep modules")
- the examples in part 3 (Balance) are trivial and what is worse - don't really illustrate the utility of the theory; that's where the author should "sell" his ideas, and that's probably why the book didn't achieve a commercial success ;/ (at least it doesn't look popular in the industry)
- chapter 12 - about the fractal geometry - I know that all models are bad, but some are useful, but this simplification is actually more misleading than useful :( if we take a look key properties of fractals (self-similarity, infinite complexity, iterative formation, ...) - pretty much NONE of them apply to software arch, the only resembles is that you can keep adding to elements at many levels adding more abstractions both "in" and "out"; the whole chapter is rather a waste of ink ;/

I also missed a bunch of things here ;/
- some metric proposals
- a generalised model (c4-like) that could be a proper foundation for defining distance
- some proximity measure (or heuristics) for things "belonging together"
- some more consideration on "model coupling" (which for me ... is not a coupling)
- some more practical advice on tools/techniques that can be used (e.g., for statical analysis with given tech stacks)
etc.

So, in the end.
I totally APPRECIATE the effort.
I totally believe there was an IDEA behind this book (and a lot of work, and a lot of good will).
But it didn't work out, sadly ;/

Still, no star rating. If you're very hooked on the topic, read this book anyway - make your own opinion, I'd love to know what you think (and the author as well, I think).

[Bugzmanov · Rating 5 out of 5]

This is the best exploration of the topic of coupling. The book provides solid mental model on how to think and measure coupling. It even offers mathematical models on how to evaluate design decisions.
I would say this is a pretty good sequel to "Philosophy of software design": it covers same ideas - complexity, modularity and abstractions to achieve balanced software growth. But this book drills down from the perspective of a coupling and stays very focused on the topic.
Still short and easy read.

[Tobias Lindqvist · Rating 5 out of 5]

The best technical book I read in a long time. This book gives a way to communicate about heuristics many developers have intuitively.

The book is written in a very easy and understandable manner.

”Changes makes implicit complexity explicit.”

[Christoph Kappel · Rating 4 out of 5]

This book is a bit difficult to rate, because it has to main parts and not both of them work well. The first part explains the general idea of coupling, cohesion and also introduces the term connascene, which I know from books like Your Code As a Crime Scene: Use Forensic Techniques to Arrest Defects, Bottlenecks, and Bad Design in Your Programs.

It does a pretty well job in laying out the problems with it and also offers ways to kind of mitigate them.

The remaining part introduces the design tool to balance coupling and I can't see right know how this is supposed to help. To me it feels like a good tool to discover coupling and also to make it in a way visible to developers, but using it to design it feels weird.

[Vladimir Ivanov · Rating 5 out of 5]

So I finished "Balancing Coupling" and I love it so much that I decided to write a review.

First time I met Vlad Khononov in 2022 in Barcelona on GSAS conference, listening to his talk (in coop. with with Sonya Natanzon) about pragmatic approaches to Architecture metrics. Back then I poorly realized why, but I felt the importance of the subject matter. Now, looking at my notes, I can see that the magic formula was already there:
"Modularity = Integration Strength XOR Integration Distance", without the "Volatility" yet, though (at least in my notes).

Then "Learning DDD" followed, community posts here and there and I realised that I see Vladikk's name as often as Vaughn Vernon or Gregor Hohpe, who are my other favorite authors.

Now after 2.5 years, theory of Systems, particularly Systems Complexity and Modularity are concepts of my top interest at work and beyond, and this book is a great contribution into my understanding of these things. I strongly believe that every Professional Software Engineer has to read it, this is one of those books that not just gives a knowledge, but improves the thinking process. It is also very friendly to those without background in Systems Thinking or DDD, via grounding abstractions and providing clear examples.

What I miss, is the way to automatically measure Integration Strength in practice, to use the formula on the codebase at work. We probably will try anyways, starting from fuzzy categories. I also consider integrating an LLM here to analyse Integration Strength semantically and contextually, because it measures "shared knowledge", sounds like an LLM task to me 🙂

I also like how the formula adds to Robert Martin's Abstractness-Instability. While increasing abstractness of an instable (responsible) module we effectively reduce an Integration Strength with an upstream module for its clients, because a good abstraction as well as a good contract, - both are about a minimum amount of knowledge used in the integration. I think further insights may be found here.

Thank you! 🙂

[Boris · Rating 5 out of 5]

One of the best I have ever read.

It's like remake of old books and modernisation of existing body of knowledge.

[Avraam Mavridis · Rating 4 out of 5]

Pretty sold in-depth exploration on different levels of coupling in software/system design and frameworks to identify them. It could have more examples on how to "un-couple" things.

[Recai Cansız]

This book gives the idea coupling and chosen also what is the behind complexity and understandably.