Domain Event
A record of something significant that happened in the business domain, used to communicate state changes and trigger side effects across system boundaries.
Also known as: Domain Events, Business Event
Category: Software Development
Tags: domain-driven-design, software-design, architecture, patterns, event-driven
Explanation
A Domain Event is a DDD pattern that captures something meaningful that happened in the domain—a fact that domain experts care about. Unlike technical events (button clicks, HTTP requests), domain events express business-significant occurrences in the ubiquitous language: 'OrderPlaced,' 'PaymentReceived,' 'InventoryDepleted,' 'CustomerUpgraded.'
**Key characteristics:**
- **Immutable**: Events represent things that already happened—they cannot be changed or undone, only compensated for
- **Past tense**: Named in past tense to emphasize they are facts ('OrderShipped,' not 'ShipOrder')
- **Self-contained**: Carry enough information for consumers to act without querying back to the source
- **Domain-meaningful**: Express business concepts, not technical implementation details
**Why domain events matter:**
- **Decoupling**: Bounded contexts can communicate through events without direct dependencies. The publishing context doesn't need to know who listens
- **Audit trail**: Events provide a natural history of what happened in the system
- **Eventual consistency**: Enable asynchronous processing across aggregate boundaries and bounded contexts
- **Extensibility**: New behaviors can be added by subscribing to existing events without modifying the publisher
**Patterns and usage:**
- **Internal events**: Raised within a bounded context to coordinate between aggregates (e.g., after saving an Order, notify Inventory)
- **Integration events**: Published across bounded contexts or services via message brokers (Kafka, RabbitMQ, etc.)
- **Event sourcing**: When domain events become the primary source of truth—state is derived by replaying events
- **Event-driven architecture**: Building entire systems around the flow of domain events
**Design considerations:**
- Include a timestamp, event type, aggregate ID, and relevant data
- Version events to handle schema evolution
- Design for idempotent handling (consumers should handle duplicate events gracefully)
- Consider event ordering guarantees required by your domain
Related Concepts
← Back to all concepts