Glossary
Event sourcing comes with its own vocabulary, and the same word can mean subtly different things in different products. This page is the single source of truth for what each term means in Chronicle. Where a term has a fuller treatment, the definition links to it.
Aggregate
Section titled “Aggregate”A consistency boundary around a single entity’s stream of events — for example one bank account or one order. All decisions for that entity are made against its own events. When you don’t need a whole-entity boundary, prefer a Dynamic Consistency Boundary.
Constraint
Section titled “Constraint”A rule Chronicle enforces as events are appended — for example “this email address must be unique across all customers.” A constraint can reject an append, which is how invariants are protected without reading a separate read model first. See Constraints.
Dynamic Consistency Boundary (DCB)
Section titled “Dynamic Consistency Boundary (DCB)”A consistency boundary defined by the decision being made rather than by a fixed aggregate. Instead of loading an entire entity, you scope a decision to exactly the events that matter to it. See Dynamic Consistency Boundary.
An immutable record of something that happened — a fact, in the past tense (OrderPlaced, AddressChanged). Events are never updated or deleted; new facts supersede old ones. An event carries only the data that was true at the moment it occurred. See Event.
Event Log
Section titled “Event Log”The default event sequence in an event store. When you append without naming a sequence, the event goes to the event log.
Event Metadata / Tags
Section titled “Event Metadata / Tags”Contextual information attached to an event that is not part of the domain fact itself — timestamps, correlation IDs, and user-defined tags used to filter or route events. See Event Metadata Tags.
Event Sequence
Section titled “Event Sequence”An ordered, append-only series of events. The event log is the default sequence; you can define additional sequences for specialized streams. See Event Sequence.
Event Source
Section titled “Event Source”The thing an event is about — the source of the change, such as a specific customer or order. Events that share an event source form that source’s stream. See Event Source.
Event Source ID
Section titled “Event Source ID”The strongly-typed identifier of an event source (for example a CustomerId). It is the key Chronicle uses to group and replay an entity’s events.
Event Store
Section titled “Event Store”The top-level container for everything in a bounded context: event sequences, observers, projections, and read models. You obtain one from the client and work within it. See Event Store.
Event Type
Section titled “Event Type”The schema and identity of a kind of event, declared with [EventType]. Chronicle validates appended events against their registered type and supports evolving them over time. See Event Type and Event Type Migrations.
Namespace
Section titled “Namespace”An isolation boundary within an event store, most often used for multi-tenancy — each tenant’s events live in their own namespace while sharing the same model. See Namespaces.
Observer
Section titled “Observer”The umbrella term for anything that watches an event sequence and reacts as events arrive. Projections, reducers, and reactors are all observers; they differ in what they do with the events. See Observers.
Projection
Section titled “Projection”An observer that builds a read model by mapping and merging events into a document — declaratively, with no hand-written update code. Use a projection when the read side is shaped like data. See Projection.
Reactor
Section titled “Reactor”An observer that produces side effects — sending a notification, calling an external system, or triggering a command. Reactors do things; they do not build state. They must be idempotent because they may run more than once. See Reactors.
Read Model
Section titled “Read Model”A purpose-built, queryable view of state derived from events — the “read” side of CQRS. Read models are specialized per use case rather than shared, so they stay simple and fast. See Read Models.
Reducer
Section titled “Reducer”An observer that folds events into a value using imperative code you write, for cases a declarative projection can’t express cleanly. See Reducers.
Replay
Section titled “Replay”Re-running an observer over historical events to rebuild its read model from scratch — for example after changing a projection. Because events are the source of truth, read models are always disposable and rebuildable.
The destination a projection writes its read model to — MongoDB by default, with other stores available through extensions. See Sinks.
Subject
Section titled “Subject”An observable stream you can subscribe to for real-time updates — the mechanism behind reactive queries that push new data to clients as events arrive. See Subject.
Tail Sequence Number
Section titled “Tail Sequence Number”The sequence number of the most recent event in an event sequence. EventSequenceNumber.First is 0, so an empty log has no tail and the first appended event sits at First.
Tenant
Section titled “Tenant”An isolated consumer of the system whose data must not mix with others’. In Chronicle, tenants are typically separated using namespaces.