For AI agents: the complete documentation index is available at /llms.txt, the full documentation bundle is available at /llms-full.txt, and this page is available as Markdown at /learn/event-driven-architecture.md.

Event-driven architecture: facts and reactions

An event-driven system connects parts of an application through facts that have occurred. A publisher records a fact; subscribers decide what it means for their own responsibilities.

Messages and meaning

KindMeaningPharos example
CommandRequest for an owner to decide or actSetPartyAccessState
Domain eventPrivate fact in an owner's languagePartyAuthenticationChanged
QueryRequest for informationGetProjectIntegrationSnapshot
ReplyRecorded result of a requestchanged or unchanged command outcome

A message is a delivery unit. RabbitMQ supplies transport; contracts and ownership define the business meaning. A consumer's unfinished reaction leaves the original fact intact.

Domain facts and integration contracts

A domain event expresses a fact in the owner's model. An integration event is a published contract with compatibility obligations. Owner adaptors map between them. Shared infrastructure supplies delivery mechanisms.

Party's private facts carry canonical identity and the authentication generation. The domain definitions exclude issuer, subject, proof references and profile attributes. Read the context guide for the published mappings and receiving boundary.

The precise number of private/public deliveries belongs to the owner's contract. Select a durable hand-off and its recovery owner explicitly; a generic teaching diagram cannot establish a particular service's registration or activation.

Contract design

Published schemas identify the occurrence and the facts a consumer may use. Edit contract sources and generators, regenerate with pnpm generate:contracts, and check wire identities and stored-byte compatibility separately from drift.

An event ID identifies a fact or message; correlation groups a workflow; causation identifies a trigger; aggregate identity and revision identify business state. These identities support different deduplication and ordering requirements.

Event notification, event-carried state transfer and event sourcing have different purposes. Current-state persistence remains the platform default. Operational evidence must expose pending work and recovery even when queues are empty.

Next: Consistency and delivery.

Adapted from the architecture reference, with Pharos examples.

Page source

Source snapshot ยท Revision f928834c8.