Stamp Coupling

Core Idea

Stamp Coupling (also called data-structured coupling) occurs when modules share a composite data structure but each uses only a subset of fields.

Definition

Stamp Coupling (also called data-structured coupling) occurs when modules share a composite data structure but each uses only a subset of fields. This creates unnecessary coupling because modules must understand the complete structure even when needing only specific elements.

Stamp coupling represents medium-level coupling—tighter than data coupling (passing primitives) but looser than content coupling (direct internal access). Originated in structured programming research, documented by Stevens, Myers & Constantine (1974).

Key Characteristics

• Composite structure sharing: Modules pass entire records/objects rather than individual fields
• Partial usage: Receiving module uses only a subset of fields
• Change propagation: Modifications to unused fields can force recompilation/redeployment of consumers
• Implicit dependencies: Interface obscures which fields are actually used
• API over-fetching: Common in REST APIs returning complete entities when clients need specific attributes

Examples

• Function calls: Passing entire Customer object to calculateDiscount() when only customerType and purchaseHistory are needed
• Message passing: Publishing complete order events with 50 fields when consumers use 3-5 fields

Why It Matters

Stamp coupling increases maintenance burden through hidden dependencies and degrades Modularity by forcing modules to understand structures beyond their needs.

In distributed architectures, it increases network payloads, exposes data across service boundaries, and complicates contract evolution—structure changes require consumer updates even for unused fields.

Data coupling (passing only needed parameters) makes dependencies explicit and is the preferred alternative. Modern patterns like GraphQL combat stamp coupling by letting clients specify required fields. In microservices, using purpose-specific contracts instead of shared domain DTOs avoids cross-boundary stamp coupling.

Related Concepts

• Coupling - Parent concept encompassing all coupling types
• Contract - Interface agreements that stamp coupling can obscure
• Modularity - Stamp coupling degrades independent module evolution
• Semantic-Coupling - Similar hidden dependencies through shared domain knowledge
• Implementation-Coupling - Architectural coupling that stamp coupling can create
• Static-Coupling - Compile-time dependencies from shared structures
• Bounded-Context - DDD pattern for managing data structure boundaries

Sources

• Stevens, W.P., Myers, G.J., and Constantine, L.L. (1974). “Structured Design.” IBM Systems Journal, Vol. 13, No. 2, pp. 115-139. Original formalization of coupling types.

• Myers, Glenford J. (1975). Reliable Software Through Composite Design. Van Nostrand Reinhold. Detailed coupling taxonomy.

• Wikipedia Contributors (2026). “Coupling (computer programming).” https://en.wikipedia.org/wiki/Coupling_(computer_programming)

• Khononov, Vladik (2020). “Balancing Coupling in Distributed Systems.” DDD Europe. https://www.infoq.com/news/2020/02/balancing-coupling-ddd-europe/

• Microsoft (2026). “Web API Design Best Practices.” https://learn.microsoft.com/en-us/azure/architecture/best-practices/api-design

• Ford, N., Richards, M., Sadalage, P., and Dehghani, Z. (2022). Software Architecture: The Hard Parts. O’Reilly. ISBN: 9781492086895.

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.