A Bounded Context defines the limits within which a specific domain model is consistent, meaningful, and internally coherent. It provides **semantic boundaries** that separate one part of a system from another in terms of language, logic, and purpose.
Bounded contexts are a foundational concept in Domain-Driven Design. They help large or decentralized systems avoid confusion, coupling, and ambiguity—especially where different subdomains or teams are involved.
# Why It Matters In federated and modular systems like the Federated Social Pinning Service, different contexts may have different definitions of "identity", "verification", or "pin". Bounded contexts allow each part of the system to use its own terminology, data shape, and validation rules without conflict.
# Key Properties - Ubiquitous Language: Each bounded context has its own vocabulary that is consistent and shared between domain experts and developers - Isolation: Code and data inside a context follow rules that may not apply outside it - Integration: Communication between contexts must be explicit—via adapters, contracts, or translation layers
# Examples in Anarchive Some sample bounded contexts in the Anarchive ecosystem: - Social Layer: Deals with human relationships, reputation, and reciprocity - Verification Mesh: Operates with measurable truth, uptime checks, and cryptographic validation - Pinning Services: Focuses on external APIs, storage capacity, and pin lifetimes - Metadata and Naming: Concerned with canonical naming and minimal schemas Each of these areas has different values, terms, and logic—and should not leak assumptions into other contexts.
# Boundaries and Interfaces Bounded contexts may communicate via: - Shared protocols (e.g. IPFS CID) - Data contracts (e.g. JSON metadata schemas) - Federated wiki links (loose semantic coupling) - Explicit anti-corruption layers (if one model must protect itself from another) This makes the architecture more robust, understandable, and adaptable.
# Visualization In a Domain Model Diagram, bounded contexts are typically drawn as separate regions with labeled interfaces. See also: Federated Social Pinning Service → Domain Design graph.
# When to Define One Define a bounded context when: - Teams speak different "languages" for the same word (e.g. “user” in security vs. social trust) - The same data means different things in different places - You want to enforce clean boundaries in an evolving, federated, or collaborative system A bounded context is not just a code module or service—it’s a **semantic boundary of meaning**.