领域驱动设计限界上下文架构

Architecture

DDD 限界上下文架构图，订单、客户、物流和计费上下文通过防腐层、共享内核和定义集成关系的上下文映射连接。该模板可视化战略 DDD 模式，将复杂领域分解为通过明确定义的集成事件通信的自治限界上下文。对于将领域驱动设计应用于大规模企业系统的架构师至关重要。

下载 .fz 文件

完整 FlowZap 代码

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"]
}

为什么需要这个工作流？

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.

工作原理

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.

替代方案

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	领域驱动设计限界上下文架构
Category	Architecture
Steps	6 workflow steps
Format	FlowZap Code (.fz file)