# 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

| Kind | Meaning | Pharos example |
| --- | --- | --- |
| Command | Request for an owner to decide or act | SetPartyAccessState |
| Domain event | Private fact in an owner's language | PartyAuthenticationChanged |
| Query | Request for information | GetProjectIntegrationSnapshot |
| Reply | Recorded result of a request | changed 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](../../../services/beto/contexts/party_governance/domain/events.go)
exclude issuer, subject, proof references and profile attributes. Read the
[context guide](../../../services/beto/contexts/party_governance/README.md) for the
published mappings and receiving boundary.

```mermaid
flowchart LR
    Root[Owner transition] --> Intent[Committed outgoing intent]
    Intent --> Relay[Delivery adaptor]
    Relay --> Consumer[Consumer-owned reaction]
    Consumer --> Recovery[Persisted progress and recovery]
```

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](consistency-and-delivery.md).

Adapted from the [architecture reference](attribution.md), with Pharos examples.