Event Types
Understanding different types of events and how to design them for your domain.
Event types define the structure and meaning of events in your system. A well-designed event type captures not just what happened, but also provides enough context to understand why and how it happened.
Events should be named in the past tense, as they represent facts that have already occurred. For example: OrderPlaced,PaymentProcessed, orUserRegistered.
Events that represent meaningful business occurrences in your domain.
These events capture the core business logic and are typically the most important events in your system.
Technical events that track system-level activities.
These events help with monitoring, debugging, and maintaining the system infrastructure.
Events published to communicate with other bounded contexts or services.
These events form the contract between different parts of your distributed system.
Events that capture failures or exceptional situations.
These events help track and handle error conditions in a structured way.
A well-designed event typically contains the following information:
{
"eventId": "550e8400-e29b-41d4-a716-446655440000",
"eventType": "OrderPlaced",
"timestamp": "2024-01-15T10:30:00Z",
"aggregateId": "order-12345",
"aggregateType": "Order",
"version": 1,
"data": {
"customerId": "customer-789",
"items": [
{
"productId": "product-456",
"quantity": 2,
"price": 29.99
}
],
"totalAmount": 59.98,
"currency": "USD"
},
"metadata": {
"userId": "user-123",
"correlationId": "correlation-abc",
"causationId": "command-xyz"
}
}- •Use past tense: Events represent facts that have occurred
- •Be specific: Prefer "OrderShipped" over generic "OrderUpdated"
- •Include context: Add all necessary information to understand the event in isolation
- •Keep them immutable: Once published, events should never change
- •Version your events: Plan for schema evolution from the start
- •Make them self-contained: Avoid references that might not exist in the future
- •Use meaningful names: Event names should clearly communicate what happened
Fine-grained events: Multiple small events for each state change. Provides detailed history but can lead to many events.
Coarse-grained events: Fewer, more comprehensive events. Simpler to manage but might lose granular detail.
The right granularity depends on your business requirements, query patterns, and how you need to reconstruct state.