Manu's Vault

Semantic Coupling

5 min readStatus:Seedling

Core Idea

Semantic coupling occurs when components depend on shared business or technical concepts, making changes to these meanings ripple across systems—coupling inherent to the problem domain that cannot be eliminated by design alone.

Definition

Semantic coupling occurs when components depend on shared business or technical concepts, making changes to these meanings ripple across multiple systems. Unlike structural or implementation coupling (which can be reduced through better design), semantic coupling represents inherent dependencies in the problem domain itself—coupling that cannot be eliminated because it reflects genuine business logic relationships.

Neal Ford distinguishes semantic coupling as “the inherent natural coupling of a workflow.” In a book ordering system, for example, you must have a catalog, user, inventory, and warehouse. These dependencies are not implementation choices—they’re intrinsic to what an ordering system means. While you can model semantic coupling in different ways, you cannot reduce it through implementation—you can only make it worse.

Key Characteristics

  • Inherent to the domain: Arises from how business concepts naturally relate, not from technical design choices

    • Example: Payment and Order must coordinate in e-commerce because the business process requires it
    • Example: Customer and Policy definitions must align in insurance systems

  • Changes propagate unavoidably: When domain concept meanings evolve, all coupled components must update

    • Business evolution (new regulations, changed definitions)
    • Deeper domain insights (refined understanding of “preferred customer”)
    • Terminology shifts (redefinition of “active subscription”)

  • Exists at the information level: Created by shared understanding of data meanings and business rules

    • Schema dependencies (what fields mean, not just what types they are)
    • Business rule alignment (validation logic, state transitions)
    • Temporal semantics (when events occur relative to each other)

  • Cannot be eliminated, only managed: The goal is making semantic coupling explicit rather than pretending it doesn’t exist

    • Document shared concepts clearly (ubiquitous language in DDD)
    • Use bounded contexts to limit semantic coupling scope
    • Accept coordination requirements where semantics genuinely overlap

  • Distinct from implementation coupling: Technical choices add unnecessary coupling on top of semantic coupling

    • Semantic: Order must know about Inventory (business logic requirement)
    • Implementation: Order directly queries Inventory’s database (technical coupling choice)

Examples

  • Domain-related semantic coupling:

    • Multiple services defining “customer” differently must synchronize when the business clarifies the definition
    • Insurance services sharing “policy,” “claim,” and “coverage” concepts require aligned meanings

  • Technical semantic coupling:

    • Services using SOAP protocol depend on protocol semantics—changing it requires consumer updates
    • Event-driven systems where consumers expect specific event schemas—removing fields breaks dependent logic

  • Measured through information retrieval:

    • Research shows semantic coupling can be detected by analyzing shared terminology in code identifiers and comments
    • Over 70% of semantically related classes co-change, validating semantic coupling’s practical impact

Why It Matters

Architectural honesty: Architects must distinguish unavoidable semantic coupling from reducible implementation coupling. Attempting to “decouple” semantically related components through technical tricks (like event buses or message queues) only obscures the coupling—it doesn’t eliminate it. As Ford notes, modeling semantic coupling poorly increases overall coupling rather than reducing it.

Design decisions: Understanding semantic coupling guides critical trade-offs. When complexity of shared semantics increases, centralized coordination (orchestration) may be more honest than pretending components are independent (choreography). Bounded contexts in DDD explicitly acknowledge semantic coupling boundaries—components within a context share models; components across contexts must translate.

Change impact analysis: Semantic coupling predicts where changes propagate. Empirical research shows semantic coupling metrics (measuring shared vocabulary) better predict co-change than structural metrics alone. Architects should map semantic coupling explicitly to anticipate ripple effects from domain evolution.

Sources

  • Ford, Neal, Mark Richards, Pramod Sadalage, and Zhamak Dehghani (2022). Software Architecture: The Hard Parts - Modern Trade-Off Analyses for Distributed Architectures. O’Reilly Media. ISBN: 9781492086895.

    • Multiple chapters on coupling types and decomposition trade-offs
    • Distinction between semantic and implementation coupling

  • Olbrich, Steffen, Daniela S. Cruzes, and Dag I. K. Sjøberg (2010). “Are All Code Smells Harmful? A Study of God Classes and Brain Classes in the Evolution of Three Open Source Systems.” IEEE International Conference on Software Maintenance.

  • Bavota, Gabriele, Andrea De Lucia, Andrian Marcus, and Rocco Oliveto (2013). “A Two-Step Technique for Extract Class Refactoring.” Proceedings of the 28th IEEE/ACM International Conference on Automated Software Engineering (ASE).

  • Khononov, Vladik (2020). “Balancing Coupling in Distributed Systems.” DDD Europe Conference.

  • Ford, Neal (2019). “Semantic Coupling.” Programming Brain blog.

  • Coupling.dev (2024). “Semantic coupling | Balancing Coupling in Software Design.”

Note

This content was drafted with assistance from AI tools for research, organization, and initial content generation. All final content has been reviewed, fact-checked, and edited by the author to ensure accuracy and alignment with the author’s intentions and perspective.

Graph View

Backlinks