事件驱动领域事件架构

Architecture

领域事件架构图，展示聚合根如何引发领域事件，这些事件既在进程内分发给本地处理器，也跨边界分发给其他限界上下文中的集成事件消费者。该模板模拟 DDD 事件模式，领域逻辑通过干净的事件分发器触发副作用，保持领域和基础设施关注点的分离。对于实施基于事件集成的领域驱动设计的团队至关重要。

下载 .fz 文件

完整 FlowZap 代码

Domain { # Domain Layer
n1: circle label:"Business Operation"
n2: rectangle label:"Aggregate Root"
n3: rectangle label:"Apply Domain Logic"
n4: rectangle label:"Raise Domain Event"
n5: rectangle label:"Commit Unit of Work"
n1.handle(right) -> n2.handle(left)
n2.handle(right) -> n3.handle(left) [label="State Transition"]
n3.handle(right) -> n4.handle(left) [label="OrderShipped"]
n4.handle(right) -> n5.handle(left) [label="Transactional"]
n5.handle(bottom) -> Dispatcher.n6.handle(top) [label="After Commit"]
}
Dispatcher { # Event Dispatcher
n6: rectangle label:"Collect Pending Events"
n7: rectangle label:"Resolve Event Handlers"
n8: rectangle label:"Dispatch In-Process"
n9: rectangle label:"Dispatch Cross-Boundary"
n6.handle(right) -> n7.handle(left) [label="Event Queue"]
n7.handle(right) -> n8.handle(left) [label="Same Bounded Context"]
n7.handle(bottom) -> n9.handle(top) [label="External Context"]
n8.handle(bottom) -> Handlers.n10.handle(top) [label="Sync"]
n9.handle(bottom) -> Integration.n14.handle(top) [label="Async"]
}
Handlers { # In-Process Handlers
n10: rectangle label:"Update Read Cache"
n11: rectangle label:"Send Notification"
n12: rectangle label:"Trigger Side Effect"
n13: rectangle label:"Log Audit Entry"
n10.handle(right) -> n11.handle(left)
n11.handle(right) -> n12.handle(left)
n12.handle(right) -> n13.handle(left)
}
Integration { # Integration Events
n14: rectangle label:"Publish to Message Bus"
n15: rectangle label:"Billing Context Subscribes"
n16: rectangle label:"Shipping Context Subscribes"
n17: rectangle label:"Analytics Context Subscribes"
n14.handle(right) -> n15.handle(left) [label="BillingEvent"]
n14.handle(bottom) -> n16.handle(top) [label="ShippingEvent"]
n15.handle(right) -> n17.handle(left)
n16.handle(right) -> n17.handle(left)
}

为什么需要这个工作流？

Tightly coupling side effects (notifications, cache updates, audit logs) to domain logic makes business rules harder to test and modify. Domain events decouple the "what happened" from the "what should happen next," enabling clean separation between core business logic and infrastructure concerns.

工作原理

Step 1: An aggregate root performs a business operation and raises a domain event.
Step 2: The unit of work commits the transaction and hands events to the dispatcher.
Step 3: In-process handlers execute synchronous side effects within the same bounded context.
Step 4: Cross-boundary events are published to a message bus for other contexts.
Step 5: Billing, Shipping, and Analytics contexts subscribe to relevant integration events.
Step 6: Each handler operates independently, so failures in one do not affect others.

替代方案

Direct method calls between services create tight coupling. Mediator patterns (MediatR) handle in-process events but not cross-service. This template shows both in-process and cross-boundary event dispatching.

Key Facts

Template Name	事件驱动领域事件架构
Category	Architecture
Steps	6 workflow steps
Format	FlowZap Code (.fz file)