Command
Domain decision
Domain event
Event store
Projection
A command reaches the application → the application applies domain rules and produces events → Chronacta appends them to a stream → projections build read models for queries.

Who this material is for

Developers and architects designing an application around domain events. The material distinguishes application responsibilities from event-store infrastructure and explains the operational consequences of the design.

If you already know the model, start with the Chronacta quickstart or the installation quickstart.

What you will cover

  1. Understand events as the source of truth and distinguish Event Sourcing from an audit log.
  2. Map command handlers, aggregates, repositories, and the event store.
  3. Handle expected versions, conflicts, and retries.
  4. Implement an order aggregate and a separate read model.
  5. Rebuild projections and account for eventual consistency.
  6. Run Chronacta and test the complete processing path.

Each article includes an exercise that tests an architectural responsibility or failure scenario.

Learning path

What is Event Sourcing?

Understand the distinction between storing current state and using events as the source of truth.

From command to event

Handle a command, enforce aggregate invariants, append events, and resolve concurrency conflicts.

Projections and replay

Build read models, manage checkpoints, and replay events without repeating business operations.

Chronacta quickstart

Run a local server and test appends, conflicts, subscriptions, and read-model rebuilds.

Continue exploring

Read the product overview for Chronacta's capabilities, explore architectural patterns, and compare editions for deployment options. Exact API contracts and operational procedures are in the documentation.

This path contains six articles. Event versioning, integration contracts, and recovery procedures require further design for each application.