Balancing Coupling in Software Design - Vlad Khononov - DDD Europe 2023

Domain-Driven Design Europe 2023
dddeurope.com - / ddd_eu - newsletter.ddd... / domain-driven-design-e...
Organised by Aardling (aardling.eu/)
We are used to treating coupling as the necessary evil. Hence, we aim to break systems apart into the smallest services possible, in the ever-lasting quest of decoupling everything. But what results are we getting by following this reasoning? - Instead of the promised land of evolvable systems, many such “decouple everything” endeavors lead straight into the chains of distributed monoliths. Can we do better? What if there is a better way to handle coupling in distributed systems? Or even, what if instead of fighting coupling, we can use it as a heuristic for designing systems that are actually evolvable and maintainable? That’s exactly what you will learn in this session: what coupling is, and how you can use it as a design tool. We will start by taking a journey through time, and explore the different models of evaluating coupling. Next, we will combine the existing knowledge into a coherent model - a simple function for evaluating a system’s decomposition into components. This function will allow you to assess the expected effort for evolving a system and use it as a heuristic for optimizing architectural design decisions.
Vlad Khononov is a software architect with over 20 years of industry experience, during which he has worked for companies large and small in roles ranging from webmaster to chief architect. Vlad is a long-time proponent of domain-driven design and evolutionary architecture and currently helps companies make sense of their business domains, untangle monoliths, and tackle complex architectural challenges.

[@michaelploed]

This video should be a must-watch to everyone in software design & architecture

[@stephendgreen1502]

Excellent. Very clear. Very accurate.

[@murillorocha5436]

Great presentation. Hope Vlad's book comes out soon.

[@christophercollett5665]

TL;DR: Pain = Strength * Volatility * Distance.
Reduce one of them to 0 to minimize the pain of necessary coupling.

[@tristanludowyk9579]

Great talk thank you!

[@LjuboThePro]

Good stuff.

[@deekay2091]

DDD hero ❤

[@ulfdellbrugge827]

would be better if it wasn't hx-properity but part of html6

[@djgreyjoy1495]

The presented coupling ontology seems to require more thought

[@usabilist]

It is a talent to speak for about one hour juggling with words but do not come to any practical application.

[@seNick7]

Last 20 minutes were all about practical implementations. The implications aren't revolutionary though

[@nichtverstehen2045]

nobody is worried about coupling like you. people just do their jobs. more over, in most situations it makes sense to ignore problems like coupling all together, because software development is not really driven by anything but freaking profit. end of story. non-profit projects just dream to get f...d aka bought.

[@fran_sanchez_yt]

Coupling (and bad developers) is one of the main reasons for a company to fail... Code becomes hard to change, a lot of cruft is required for every minor change and innovation and improvement is drastically reduced because the system is not malleable enough... People get tired and demotivated and leave... No one is going to get through a due diligence for an acquisition with such a pile of garbage.

[@cheesebusiness]

You are not experienced enough to realize that you have problems that waste or will waste the money of the business

[@nichtverstehen2045]

@@cheesebusiness how do you know anything about me? discussing opponent's personality is the last resort for those who has nothing else to backup their argument.