← ExamplesGitHub
EXAMPLE / EVENTS

An event-driven boundary.

Assume an Order Service publishes an OrderConfirmed event consumed by a Fulfillment Service.

Domain

Order fulfillment.

Boundary

  • The Order Service owns the fact that an order was confirmed.
  • The Fulfillment Service owns fulfillment state and downstream execution.
  • Neither service owns the other's internal state.

Contract

Event: OrderConfirmed
Version: 1
Key: order_id
Required fields: event_id, order_id, occurred_at
Delivery: at-least-once
Ordering: per order_id
Consumer requirement: idempotent processing
Schema change: additive changes are compatible; semantic changes require version review

Execution

Producer and consumer teams can implement independently once the event contract, ownership, and verification evidence are agreed.

Verification

  • Event schema compatibility check.
  • Consumer fixture tests using representative producer events.
  • Duplicate-delivery test.
  • Ordering test for a single order key.
  • Failure-path and retry verification.
Important: “at-least-once” is a contract property. It does not by itself guarantee exactly-once business effects; the consumer must define and verify idempotency behaviour.