In a system where placing an order should raise an OrderPlaced domain event, should the domain logic that decides to raise that event publish it directly to an event bus/message broker itself, or should it merely return/collect the event for the application service to publish after the transaction commits? Explain the reasoning.

## Raising an event versus dispatching it This question sits right at the boundary between the application-service and domain-service split and a closely related concern: where domain events get raised versus where they get dispatched. The short answer is that domain logic should be responsible for deciding an event occurred, but not for transmitting it — and untangling why requires looking at both the dependency direction and the transactional-consistency problem. ## On dependency direction On dependency direction: domain services and entities are meant to be free of infrastructure concerns, and a message broker client is squarely infrastructure. If a domain service directly calls something like `messageBroker.publish(new OrderPlaced(orderId))`, the domain layer now has a hard dependency on your messaging technology — swapping brokers, or unit-testing the domain service, now requires either a real broker or a mock of one, which reintroduces exactly the infrastructure-testing cost the pure-domain-layer design was meant to avoid. The standard pattern instead has the aggregate or domain service simply record that an event occurred: - most commonly, the aggregate accumulates a private list of "uncommitted domain events" that a method like `pullDomainEvents()` returns and clears - or a domain service returns the event(s) as part of its result value Either way, an event object here is just a plain data structure (e.g., `OrderPlaced(orderId, placedAt)`), not something being transmitted — nothing about it references a broker, topic name, or serialization format. ## On transactional consistency On transactional consistency: this is the more operationally dangerous half of the reasoning. If a domain object published an event synchronously and immediately, before the surrounding transaction commits, and that transaction later rolls back — because a downstream save fails, a constraint violation triggers, or an exception is thrown two steps later in the same use case — then the event was already broadcast to the world describing a state change that never durably happened. A subscriber (say, a shipping-notification service or an analytics pipeline) receiving `OrderPlaced` would act on a phantom event, and there's no automatic way to unpublish it. This is a real, production-observed failure class often called the **dual-write problem**: you're writing to two different systems (the database and the event bus) and there's no way to make both writes atomic without extra machinery. The mitigation most production systems converge on: within the application service's single database transaction, the domain logic collects events but nothing is actually sent externally; only after the transaction successfully commits does the application service (or a dedicated event-dispatch component) actually publish. To make even that step reliable — because "commit succeeded, then the process crashes before publishing" is still a gap — many systems use the **transactional outbox pattern**: 1. the application service writes both the domain state change and a serialized representation of the event into an outbox table as part of the same database transaction 2. a separate poller/relay process reads unpublished outbox rows and sends them to the actual message broker, retrying until it succeeds 3. then marks them sent This closes the gap because the event's existence is now itself durably part of the same atomic write as the state change, and the actual broker dispatch can be retried independently without any duplicate business-state mutation. ## The trade-off worth naming The trade-off worth naming explicitly: outbox-pattern reliability adds real operational cost — - an extra table - a relay/poller process to operate and monitor - at-least-once delivery semantics that push idempotency requirements onto every consumer, since a crash between "sent to broker" and "marked sent in outbox" can cause a redelivery Teams building a low-stakes internal admin tool where an occasional missed or duplicate notification is a shrug, not an incident, may reasonably skip the outbox and just publish synchronously right after commit, accepting the small window of risk between commit and publish. The decision is a genuine cost/reliability trade-off, not a universal "always use outbox" rule — it depends on what breaks if a downstream consumer misses or double-processes an event. ## A concrete illustration A concrete illustration: an e-commerce checkout flow where `OrderPlaced` triggers both an inventory-reservation service and a customer-facing confirmation email. If the event fired before commit and the transaction then rolled back (say, a payment authorization failure discovered two steps later), inventory could be reserved and a confirmation email sent for an order that doesn't exist in the database — a directly customer-visible bug. Structuring the domain layer to only collect the event, and having the application service publish, ideally via an outbox, strictly after a successful commit, is what prevents that class of bug by construction rather than by discipline alone.