When an aggregate raises a domain event and an in-process listener reacts to it by modifying a different aggregate, should that listener's change happen in the same database transaction as the original aggregate's change? What are the consistency implications either way?

## The two rules in tension This question sits at the intersection of two DDD tactical rules: 1. an aggregate should be the sole unit of consistency and transactional boundary in your model; 2. domain events are the primary mechanism for one aggregate to trigger effects on another without directly referencing it. The tension is that if a domain event's handler runs inside the same transaction as the aggregate that raised it and also modifies a second aggregate, you've made two aggregates **transactionally consistent with each other** — exactly what the one-aggregate-per-transaction rule advises against, because it grows lock scope, increases contention, and makes each aggregate's persistence depend on another's. ## The two choices, side by side | | Listener in the same transaction | Listener after commit | |---|---|---| | Consistency | strong (ACID) consistency between order placement and stock decrement | eventually consistent across those two aggregates, even within one process | | Boundary | grows lock scope, increases contention | keeps each aggregate's persistence in its own transaction | ## Same transaction: atomic, and coupled Concretely: suppose an `Order` aggregate raises `OrderPlaced`, and a listener decrements an `Inventory` aggregate's available stock in response. If that listener runs inside the same database transaction as the order's save, both changes commit or roll back together — strong (ACID) consistency between order placement and stock decrement, so you can never observe an order that was placed but didn't decrement stock, or vice versa. This is attractive when the two facts truly must never diverge, e.g. a financial ledger debit and credit that must always balance. The cost is **coupling**: - the transaction now touches two aggregates' rows, so whatever locks each aggregate's persistence uses now contend with each other, and a spike in contention on `Inventory` rows can slow down or fail Order-placement transactions that have nothing to do with inventory conceptually; - it also means the Order use case's failure modes now include everything that can go wrong while persisting `Inventory`; - as more aggregates get pulled into the same transaction this way, the system drifts toward one where "the transaction" spans most of the domain model, defeating the purpose of drawing aggregate boundaries at all. ## After commit: independent, and eventually consistent The alternative — dispatching the listener after the originating transaction commits, but still in-process (e.g. Spring's `@TransactionalEventListener(phase = AFTER_COMMIT)`) — keeps each aggregate's persistence in its own transaction. The `Order` transaction commits on its own; only once that's durable does the Inventory-decrementing listener run, in a second, separate transaction. This preserves the aggregate-per-transaction rule and avoids the lock-contention coupling above, but introduces a real **consistency gap**: between the Order transaction committing and the Inventory listener's transaction committing, a reader could observe an order that's Placed but inventory not yet decremented. For most systems this window is milliseconds and harmless, but it's a genuine trade-off — the system is now eventually consistent across those two aggregates, even within one process. ## When the second transaction fails The sharper failure mode is what happens when the second transaction fails after the first has already committed. The `Order` is durably Placed; the `Inventory` decrement throws a constraint violation or times out. Because the first transaction already committed, there's no automatic rollback available — recovering requires either: - a retry mechanism (ideally idempotent), or - a compensating action (cancel the order, or flag it for manual reconciliation). Systems that do this well build the listener to be idempotent and retryable, and often use a durable queue or outbox-adjacent mechanism to guarantee the listener eventually runs even across a process crash between commit and dispatch — though guaranteed delivery across process boundaries belongs to the event-delivery/broker layer, not the domain-modeling decision itself. ## The rule of thumb A well-known real-world instance of choosing the after-commit path deliberately is Spring's `@TransactionalEventListener` with `AFTER_COMMIT` phase, widely used in DDD-flavored Spring Boot codebases specifically to keep an aggregate's event listeners from ever running against data that later got rolled back, while still keeping each aggregate's own save in its own transaction. The practical rule of thumb: keep each aggregate's own invariants and persistence inside one transaction; treat any effect on a second aggregate, triggered by an event the first one raised, as inherently eventually consistent, and design that second step to be safely retryable rather than assuming it will always succeed in lockstep with the first.