Architecture
A DDD bounded contexts architecture diagram with Order, Customer, Shipping, and Billing contexts connected through an anti-corruption layer, shared kernel, and context map defining integration relationships. This template visualizes the strategic DDD patterns for decomposing complex domains into autonomous bounded contexts that communicate through well-defined integration events. Critical for architects applying Domain-Driven Design to large-scale enterprise systems.
Full FlowZap Code
OrderContext { # Order Bounded Context
n1: rectangle label:"Order Aggregate"
n2: rectangle label:"Order Line Item"
n3: rectangle label:"Order Repository"
n4: rectangle label:"Order Service"
n1.handle(right) -> n2.handle(left) [label="Contains"]
n4.handle(right) -> n1.handle(left) [label="Manages"]
n4.handle(bottom) -> n3.handle(top) [label="Persists"]
n4.handle(bottom) -> ACL.n9.handle(top) [label="Integration Event"]
}
CustomerContext { # Customer Bounded Context
n5: rectangle label:"Customer Aggregate"
n6: rectangle label:"Address Value Object"
n7: rectangle label:"Customer Repository"
n8: rectangle label:"Customer Service"
n5.handle(right) -> n6.handle(left) [label="Has"]
n8.handle(right) -> n5.handle(left) [label="Manages"]
n8.handle(bottom) -> n7.handle(top) [label="Persists"]
n8.handle(bottom) -> ACL.n10.handle(top) [label="Integration Event"]
}
ACL { # Anti-Corruption Layer
n9: rectangle label:"Order-to-Shipping Translator"
n10: rectangle label:"Customer-to-Billing Translator"
n11: rectangle label:"Shared Kernel (Common Types)"
n12: rectangle label:"Context Map"
n9.handle(bottom) -> ShippingContext.n13.handle(top) [label="ShipmentRequested"]
n10.handle(bottom) -> BillingContext.n16.handle(top) [label="InvoiceRequested"]
n11.handle(right) -> n12.handle(left) [label="Defines"]
}
ShippingContext { # Shipping Bounded Context
n13: rectangle label:"Shipment Aggregate"
n14: rectangle label:"Tracking Number VO"
n15: rectangle label:"Shipping Service"
n13.handle(right) -> n14.handle(left) [label="Assigned"]
n15.handle(right) -> n13.handle(left) [label="Manages"]
}
BillingContext { # Billing Bounded Context
n16: rectangle label:"Invoice Aggregate"
n17: rectangle label:"Payment Entity"
n18: rectangle label:"Billing Service"
n16.handle(right) -> n17.handle(left) [label="Contains"]
n18.handle(right) -> n16.handle(left) [label="Manages"]
}
Why This Workflow?
Large systems with a single unified model become increasingly complex as different teams interpret the same concepts differently. Bounded contexts establish clear boundaries where each context has its own ubiquitous language, data model, and team ownership—preventing model pollution and enabling independent evolution.
How It Works
- Step 1: The domain is decomposed into bounded contexts: Order, Customer, Shipping, and Billing.
- Step 2: Each context has its own aggregate roots, entities, and repositories.
- Step 3: An anti-corruption layer translates between context-specific models at integration points.
- Step 4: Integration events carry only the data needed by the consuming context.
- Step 5: A shared kernel defines common types used across multiple contexts.
- Step 6: The context map documents relationships (upstream/downstream, conformist, partnership) between contexts.
Alternatives
A single shared model is simpler for small teams but does not scale. Microservices without DDD boundaries often create distributed monoliths. This template shows the strategic DDD patterns for decomposing complex domains.
Key Facts
| Template Name | Domain-Driven Design Bounded Contexts Architecture |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Related templates
Architecture
A domain events architecture diagram showing how aggregate roots raise domain events that are dispatched both in-process to local handlers and cross-boundary to integration event consumers in other bounded contexts. This template models the DDD event pattern where domain logic triggers side effects through a clean event dispatcher, maintaining separation between domain and infrastructure concerns. Key for teams implementing Domain-Driven Design with event-based integration.
Architecture
A microservices decomposition architecture diagram organized by business capabilities: Identity, Product Catalog, Pricing, and Order Fulfillment, each with independent data stores and APIs. This template shows how to break a monolith into services aligned with business domains, using a Backend-for-Frontend (BFF) pattern for client-specific aggregation. Useful for architects planning domain-driven microservice boundaries.
Architecture
A strangler fig migration architecture diagram showing the incremental replacement of a legacy monolith with new microservices, using a routing layer to split traffic between old and new systems. This template models the proven migration strategy where new features are built as microservices while legacy endpoints are gradually retired. Essential for teams modernizing legacy systems without risky big-bang rewrites.
Architecture
An event sourcing architecture diagram where all state changes are stored as an immutable sequence of domain events, with read projections built from the event stream and snapshot optimization for fast aggregate loading. This template shows how event sourcing eliminates data loss by preserving the complete history of every state transition. Critical for systems requiring full audit trails, temporal queries, and event replay capabilities.
Architecture
A microservices API gateway architecture diagram showing request routing, JWT authentication, rate limiting, service discovery, and response aggregation across distributed backend services. This template models the entry point for all client traffic in a microservices ecosystem, enforcing security policies before requests reach internal services. Ideal for platform engineers designing scalable API infrastructure with centralized cross-cutting concerns.
Architecture
A service mesh architecture diagram with Istio or Linkerd sidecar proxies handling mTLS encryption, traffic policies, circuit breaking, and distributed tracing across microservices. This template visualizes how a service mesh abstracts networking concerns away from application code, enabling zero-trust communication between services. Essential for teams adopting service mesh infrastructure to improve observability and security.