Architectures that were correct by the book still degrade over time. Often the cause sits outside the code: in the domain, or in the way the teams are organized.

Good frameworks for coupling exist at every level. Khononov’s coupling model gives architects a scale-independent vocabulary. The same strength levels apply from individual methods to distributed services. Team Topologies addresses the organizational level directly. Domain-Driven Design covers domain structure. Its context-map patterns reach into the organizational level.

These frameworks are individually strong. They live in different books, different communities, and different curricula. Architects encounter them at different career stages and rarely all at once.

But coupling at one of those levels often implies coupling at another. When two teams have to coordinate on every release, the cause is usually something shared underneath: code, data, or a deployment boundary. When one domain concept is spread across two services, a change to it usually forces both to deploy together. You catch these links only by looking across all four levels at once, not one book at a time.

This talk gives you a method for using those frameworks together. It presents a working model spanning four origins of coupling: domain, architecture design, code, and organization. For any coupling you encounter, the talk asks the same question: where does it come from? The answer narrows down what you can do about it.

You will leave with:

– One coupling vocabulary that spans domain, design, code, and organization.
– A way to trace any coupling back to its origin.
– Clarity about which coupling you must live with and which you can remove.

Some coupling reflects domain structure: no refactoring changes that. Some is a consequence of team organization. Some is a design choice. Seeing each for what it is, and knowing what to do about it, is the architectural skill this talk builds.