Intrusive coupling is the strongest form of dependency between software components. One component knows potentially everything about another: its public interface, private methods, shared code, or persisted state. Because changes can break hidden assumptions, stronger coupling increases the likelihood and risk of cascading changes. A component may be a function, class, module, microservice, or entire system, depending on the level of analysis. section 12.1
Typical manifestations include:
- Accessing another component’s private methods through reflection. section 12.1
- Reading or modifying another component’s persisted state directly, including reliance on its storage format. section 12.1
- Sharing code through a large god class that combines tightly coupled logic from different subdomains. section 12.1
- Changing a subsystem’s persistence format without realizing that other subsystems depend on it. section 12.1
A hidden persistence dependency
A subsystem changes the format in which its state is persisted. Other subsystems that directly depend on that format can break even though no visible API connection changed. The hidden knowledge between components makes the change risky. section 12.1
Use the figure to inspect how intrusive coupling increases the risk of change. section 12.1
Reveal intrusive coupling by modeling flows and processes, then challenging message types, names, boundaries, and decision ownership. Domain Message Flow Modeling can map interactions between subdomains and subsystems; EventStorming can provide reference scenarios. Prefer contract coupling where possible, while checking that smaller subsystems do not create excessive global complexity. section 12.6
