Concretely, how does an aggregate raise a domain event without breaking encapsulation - for example, without directly calling out to an event bus from inside its business logic?

## The design problem The core design problem this pattern solves is: an aggregate needs to announce that something happened, but an aggregate is supposed to be a pure piece of the domain model — **no knowledge of infrastructure, no dependency on a message bus or a framework publisher**, nothing that would make it hard to unit-test in isolation or move between transports. The common answer is to have the aggregate **collect** events rather than publish them. ## Mechanically, what the aggregate holds Mechanically: - the aggregate root holds a mutable, but never externally mutable, list — `private val domainEvents = mutableListOf<DomainEvent>()`; - business methods on the aggregate, after they've validated invariants and applied a state change, call a **protected** method such as `registerEvent(OrderShipped(id, trackingNumber))`, which simply appends to that internal list; - the aggregate also exposes something like `pullDomainEvents(): List<DomainEvent>` that returns and clears the list, or a read-only view plus a separate `clearEvents()`. Crucially, the aggregate's public API never accepts an event publisher, bus, or dispatcher as a dependency — raising an event is just appending to a local collection, trivially testable: a unit test can call `order.ship(...)` and assert on `order.pullDomainEvents()` without any mocking. ## Who publishes, and when Publishing then happens one layer up, in the application service (or in a repository's `save()` method, in some implementations) which already owns the transaction boundary for the use case. After it calls the aggregate's business method and persists the aggregate, it retrieves the pending events and dispatches them to whatever in-process listener mechanism the framework provides. This separation exists because the aggregate should not be deciding **when** to publish — synchronously inline, after commit, batched — since that's an application/infrastructure concern, not a domain concern. It also avoids a subtle bug: if the aggregate published events immediately as raised, and the surrounding transaction later rolled back, listeners would already have reacted to a change that never actually persisted. ## The central trade-off This is the central trade-off: collecting events and deferring publication until after a successful save buys **correctness** (listeners never see phantom events from a rolled-back transaction) at the cost of an extra hop — you can't just fire-and-forget from inside the aggregate, you have to trust the application layer to remember to pull and publish. If a developer writes a new use case and forgets to call `pullDomainEvents()`/dispatch, the event silently never fires; there's no compiler error for that omission unless the framework or a code convention enforces it, e.g. a base application service class that always pulls and publishes after every repository save. ## Two ways it goes wrong 1. **Double publication.** A related failure mode: if both the aggregate's own persistence path and a separate manual call publish the same collected events, listeners fire twice — for example, an email gets sent twice because the event was pulled and dispatched once in a generic `save()` wrapper and again explicitly by a specific use case handler that also wanted to react synchronously. Teams usually fix this by having exactly one designated place responsible for pulling and dispatching, and treating that as an architectural invariant. 2. **Accumulation.** Another common failure mode: if an aggregate instance is kept alive and reused across multiple operations, and `pullDomainEvents()` is never called to clear the list, events from an earlier operation get re-dispatched alongside new ones, or the list grows unboundedly. ## What it looks like in a real codebase A concrete, well-known instance of this pattern is how many DDD-oriented Spring/Kotlin codebases implement it: a base `AggregateRoot` class exposes `protected fun registerEvent(event: DomainEvent)` and `fun pullDomainEvents(): List<DomainEvent>`, and a generic repository wrapper calls `pullDomainEvents()` right after `save()` succeeds inside the same transaction, then hands the events to Spring's `ApplicationEventPublisher` so that `@TransactionalEventListener(phase = AFTER_COMMIT)` handlers only run once the database transaction has actually committed. This gives you the guarantee described above: an event is dispatched **if and only if** the state change it describes actually persisted.