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.
Full FlowZap Code
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)
}
Why This Workflow?
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.
How It Works
- 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.
Alternatives
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 | Event-Driven Domain Events Architecture |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Related templates
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.
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
An event-driven choreography architecture diagram where microservices coordinate through events without a central orchestrator, with Order, Payment, Inventory, and Shipping services reacting to each other's domain events. This template models the decentralized coordination pattern where each service knows only its own responsibilities and publishes events for others to consume. Best for teams favoring autonomous services over centralized workflow control.
Architecture
A saga choreography architecture diagram where Order, Payment, and Inventory services coordinate through domain events without a central orchestrator, with each service publishing and subscribing to events that drive the transaction forward or trigger compensation. This template models the decentralized saga approach where services autonomously react to events, reducing single points of failure at the cost of increased complexity in tracking saga state. Best for teams preferring service autonomy over centralized control.
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.