Coupling is the extent to which a change in one domain concept or software component affects another. It becomes change coupling when delivering a feature requires coordinated changes across codebases or teams. Even teams that can deploy independently may be unable to deliver independently if their work repeatedly crosses value streams. That coordination can add planning delays, integration work, and risk. section 1.2.1 section 12.1
Loose coupling starts with domain boundaries, not merely separate services or teams. Group concepts likely to change together into cohesive subdomains, then align team ownership and software subsystems where practical. A subsystem might be a microservice or a module in a monolith. The aim is for a common feature change to stay within one subdomain, codebase, and team—not to eliminate every dependency. section 9.0 section 2.2.2 section 12.0 section 9.2.3
A loyalty-level feature
A travel company wants rewards to reflect customer spending. The feature changes loyalty accounts, points, and rewards. If each concept belongs to a different subdomain, three codebases and teams must coordinate. Grouping the closely related concepts in one subdomain lets one team make the change in one codebase. The boundary also gives the team a clear purpose: rewarding customer loyalty. section 9.1
Assess coupling from several angles before changing a boundary:
- Map a business process collaboratively with EventStorming. Ask which concepts tend to change together, then test candidate boundaries against business, organizational, and technical concerns. section 1.2.1 section 9.0
- Map an end-to-end use case as interactions between subsystems. Each interaction is a dependency to assess; explore alternative flows rather than assuming the first design is final. section 12.2 section 12.6
- Inspect what one component knows about another. Coupling ranges from intrusive access to another component’s internals through model and functional coupling to weaker contract coupling. Stronger integration makes cascading changes more likely. section 12.1 section 12.6
- Judge the cost of a dependency in context. Consider its strength, how often the concepts change together, and their distance. Product strategy can change which concepts are volatile; zero dependencies is not a realistic target. section 9.2.3 section 9.2.2
Smaller pieces are not automatically better: they can reduce complexity within a subsystem while increasing complexity across the system. An airline kept some subdomains distinct despite shared terminology because their models served different purposes; unifying them would have added coupling for little gain. Revisit boundaries as implementation reveals new information, and prioritize changes that improve both delivery flow and business outcomes. section 12.6 section 9.3.4 section 12.0
The coupling-type diagram provides a visual scale for comparing integration strength when reviewing component dependencies. section 12.1
