Architecture
Diagramme d'architecture d'événements de domaine montrant comment les racines d'agrégat émettent des événements de domaine qui sont distribués à la fois en interne aux gestionnaires locaux et en externe aux consommateurs d'événements d'intégration dans d'autres contextes bornés. Ce modèle représente le pattern d'événements DDD où la logique de domaine déclenche des effets de bord via un dispatcher d'événements propre, maintenant la séparation entre les préoccupations de domaine et d'infrastructure. Clé pour les équipes implémentant le Domain-Driven Design avec intégration événementielle.
Code FlowZap complet
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)
}
Pourquoi ce 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.
Comment ça fonctionne
- 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 | Architecture d'événements de domaine |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Modèles associés
Architecture
Diagramme d'architecture DDD des contextes bornés avec les contextes Commande, Client, Expédition et Facturation connectés via une couche anti-corruption, un noyau partagé et une carte de contextes définissant les relations d'intégration. Ce modèle visualise les patterns stratégiques DDD pour décomposer des domaines complexes en contextes bornés autonomes qui communiquent par des événements d'intégration bien définis. Critique pour les architectes appliquant le Domain-Driven Design aux systèmes d'entreprise à grande échelle.
Architecture
Diagramme d'architecture de décomposition de microservices organisé par capacités métier : Identité, Catalogue produits, Tarification et Exécution des commandes, chacun avec des magasins de données et des API indépendants. Ce modèle montre comment découper un monolithe en services alignés sur les domaines métier, en utilisant un pattern Backend-for-Frontend (BFF) pour l'agrégation spécifique au client. Utile pour les architectes planifiant les frontières de microservices orientées domaine.
Architecture
Diagramme d'architecture de chorégraphie événementielle où les microservices se coordonnent par événements sans orchestrateur central, avec les services Commande, Paiement, Inventaire et Expédition réagissant aux événements de domaine les uns des autres. Ce modèle représente le pattern de coordination décentralisée où chaque service ne connaît que ses propres responsabilités et publie des événements pour que d'autres les consomment. Idéal pour les équipes favorisant l'autonomie des services plutôt que le contrôle centralisé des workflows.
Architecture
Diagramme d'architecture saga par chorégraphie où les services Commande, Paiement et Inventaire se coordonnent par événements de domaine sans orchestrateur central, chaque service publiant et s'abonnant à des événements qui font avancer la transaction ou déclenchent la compensation. Ce modèle représente l'approche saga décentralisée où les services réagissent de manière autonome aux événements, réduisant les points de défaillance uniques au prix d'une complexité accrue dans le suivi de l'état de la saga. Idéal pour les équipes préférant l'autonomie des services au contrôle centralisé.
Architecture
Diagramme d'architecture de passerelle API pour microservices montrant le routage des requêtes, l'authentification JWT, la limitation de débit, la découverte de services et l'agrégation des réponses à travers des services backend distribués. Ce modèle représente le point d'entrée de tout le trafic client dans un écosystème de microservices, appliquant les politiques de sécurité avant que les requêtes n'atteignent les services internes. Idéal pour les ingénieurs plateforme concevant une infrastructure API évolutive avec des préoccupations transversales centralisées.
Architecture
Diagramme d'architecture de maillage de services avec proxys sidecar Istio ou Linkerd gérant le chiffrement mTLS, les politiques de trafic, le disjoncteur et le traçage distribué à travers les microservices. Ce modèle visualise comment un maillage de services abstrait les préoccupations réseau du code applicatif, permettant une communication zero-trust entre les services. Essentiel pour les équipes adoptant une infrastructure de maillage de services pour améliorer l'observabilité et la sécurité.