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 subset of fields while ignoring others
• Schema knowledge requirement: Both modules must understand complete structure definition
• Change propagation: Modifications to unused fields can force recompilation/redeployment
• API over-fetching: Common in REST APIs returning complete entities when clients need specific attributes
• Implicit dependencies: Interface obscures which fields are actually used

Examples

• Function calls: Passing entire Customer object to calculateDiscount() when only customerType and purchaseHistory are needed
• REST APIs: Fetching full user profiles (/users/123) when displaying only username and avatar
• Message passing: Publishing complete order events with 50 fields when consumers use 3-5 fields
• Microservices: Sharing domain DTOs across boundaries instead of purpose-specific contracts

Why It Matters

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

In distributed architectures, it increases network payloads, exposes data across boundaries, and complicates contract evolution. Structure changes require consumer updates even when they don’t use modified fields.

Data coupling (passing only needed parameters) makes dependencies explicit. Modern patterns like GraphQL combat stamp coupling by letting clients specify required fields.

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.