Modeling Facts and Reactions with Domain Events
11 hours ago
- Business logic often follows 'when something happens, something else should happen' pattern.
- Coupling facts and consequences in a single script obscures the domain fact and creates maintenance issues.
- Domain events record facts in past tense, not commands; they are immutable and contain enough information to identify the fact.
- Events should be raised where the decision is made (e.g., in an aggregate) and collected until the unit of work commits.
- Handlers react independently to events, each with single responsibility and own failure handling.
- Crossing aggregate boundaries requires separate transactions for eventual consistency.
- Crossing bounded contexts uses integration events that are translated into local commands.
- Not every state change needs an event; direct calls are better when dependencies are part of one clear operation.
- Domain events improve separation, allowing independent evolution and fault tolerance for each consequence.