Glossary

Terms

• Aggregate: The consistency boundary for a stream of events on one subject; rebuilt by replaying events in order. Nimbus does not ship an Aggregate class — the idea is expressed by state, reducers, pure-core command functions, shell handlers, and EventSourcingDB preconditions (see A Note on Aggregates).
• Bounded Context: A DDD boundary within which a particular domain model, vocabulary, and rules apply consistently; in Nimbus, typically represented by a top-level domain folder (e.g. iam) and its modules (see In Depth Example).
• CloudEvents: Industry-standard envelope for Commands, Events, and Queries in Nimbus (specversion, id, type, source, data, etc.). See cloudevents.io.
• Command: A write-side message expressing intent to change state; routed and validated, then handled to produce events (see Commands).
• Correlation ID: Identifier carried across messages and HTTP requests to trace a single operation through the system (see CorrelationID Middleware).
• Core: See Pure Core — command functions, reducers, and event definitions live here.
• CQRS: Command Query Responsibility Segregation — separate models and paths for writes (commands) and reads (queries).
• Domain: A top-level business area in Nimbus folder layout (e.g. iam, billing) that groups related modules and represents the domain's bounded context (see In Depth Example).
• Domain Driven Design (DDD): Organizing code around business domains and modules (e.g. iam/users) rather than technical layers.
• Event: An immutable fact that already happened; appended to the event log and used to derive state (see Events).
• Event Bus: In-process publish/subscribe for events inside one application via NimbusEventBus (see Event Bus). In event-sourced deployments, EventSourcingDB observers often play this role across process restarts.
• Event-Driven Architecture (EDA): Style where commands, events, and queries drive behavior and integration; Nimbus is built around this (see What is Nimbus?).
• Event Log: Append-only sequence of events; the source of truth in Event Sourcing. Every other data shape is derived from it (see In Depth Example).
• Event Mapping: Conversion between Nimbus CloudEvents and EventSourcingDB records, preserving correlation ID and schemas (see Event Mapping).
• Event Observer: Background loop that receives matching events from EventSourcingDB, used to build projections (see Event Observer).
• Event Sourcing: Persisting state changes as a sequence of events; current state is derived by replaying them.
• EventSourcingDB: External event store integrated via @nimbus-cqrs/eventsourcingdb; persists the event log, supports preconditions, and delivers events to observers (see EventSourcingDB Package).
• Handler: Function registered on a router, event bus, or event observer that processes a command, query, or event matched by message type.
• Hexagonal Architecture: Ports-and-adapters style; Nimbus Pure Core / Imperative Shell aligns with it (see Architecture).
• Imperative Shell: The I/O layer (HTTP, databases, messaging) that orchestrates the pure core (see Architecture).
• Lower Bound: Observer option marking where to resume reading the event log after reconnect or restart, avoiding full replay from the beginning (see Event Observer).
• Message Type: CloudEvents type field (reverse-DNS, e.g. at.overlap.nimbus.invite-user); the router uses it to select a handler (see Commands).
• Module: A DDD slice inside a domain for one business concept (e.g. iam/users) (see In Depth Example).
• Nimbus Exception: Structured error type in @nimbus-cqrs/core with optional HTTP status and details (see Exceptions).
• OpenTelemetry: Industry-standard observability API used by Nimbus for logging, tracing, and metrics (see Observability).
• Preconditions: EventSourcingDB checks that must pass before events are appended (e.g. isSubjectPristine, isSubjectOnEventId); enforce the aggregate consistency boundary atomically (see Write Events).
• Projection: Read-side function that turns events into read model documents or views (see In Depth Example).
• Pure Core: Side-effect-free domain logic (commands, reducers, event definitions) with no I/O (see Architecture).
• Query: A read-side message requesting data without changing state (see Queries).
• Read Model: Query-optimized document or view derived from events via projections (see Queries).
• Read Side: CQRS path that serves queries and runs projections; does not append to the event log (see In Depth Example).
• Reducer: Pure function that folds an event into current state (e.g. applyEventToUserState) (see In Depth Example).
• Replay: Reading events in order to rebuild state or refresh a projection (see Read Events).
• Repository: Type-safe MongoDB access layer extending MongoDBRepository for read model persistence (see Repository).
• Router: Type-safe message dispatcher (MessageRouter) that validates and traces commands, queries, or events (see Router).
• Shell: See Imperative Shell — command handlers, HTTP routes, and persistence live here.
• State: Current shape of an aggregate after applying all relevant events via a reducer.
• Subject: CloudEvents subject — typically identifies the aggregate or entity stream an event belongs to (see Events).
• Write Side: CQRS path that accepts commands, enforces business rules, and appends events to the event log (see In Depth Example).
• Zod: Schema library used to validate commands, queries, and events in Nimbus (see Commands).