Skip to content

ADR-009 — Business Event Ontology

Status

Accepted

Context

Events are the primary integration currency in modern Unified Commerce architectures. Without a canonical event ontology, each system uses different naming conventions, payloads, and lifecycle semantics — making integration analysis, impact assessment, and event-driven documentation impossible across vendors.

Decision

UC-BoK adopts a canonical Business Event ontology defined in SPEC-009. A Business Event is a named, past-tense fact that something significant has happened in the retail domain.

Classification (four types):

Type Definition Example
Domain Event A state change within a bounded domain OrderConfirmed, PaymentCaptured
Integration Event A fact published across domain boundaries InventoryReserved, FulfillmentDispatched
Command Event A request for something to happen (imperative) ReserveInventory, CapturePayment
Notification Event An informational signal with no required response CustomerNotified, LabelPrinted

Naming rules (normative):

  1. Events use PascalCase.
  2. Events use past tense (something has happened, not will happen).
  3. Event names follow the pattern: <Object><PastParticiple> (e.g. OrderCollected, BasketAbandoned).
  4. Every event must declare its producer capability and its consumer capabilities.
  5. Events are vendor-neutral: OrderConfirmed is the canonical name regardless of which platform produces it.

Consequences

  • catalogs/events.yaml is the canonical event register.
  • Knowledge Graph edges produces and references connect Processes/Capabilities to Events.
  • Impact analysis ("what breaks if OrderConfirmed changes?") traverses event edges in the graph.
  • Vendor integration maps must translate platform-specific event names to UC-BoK canonical events.