Architecture of an event-sourced application
Keep the domain model in the application and use Chronacta as its event-storage infrastructure.
Command handler, aggregate, and repository
A command handler coordinates an operation. A repository loads an aggregate from its event stream. The aggregate applies domain rules and produces events, which the repository appends with an expected version.
The aggregate owns invariants. Neither the command handler's orchestration nor the event store replaces that responsibility.
Command and query models
In CQRS, the write model supports domain decisions. Read models support queries and can use a different structure or storage technology.
A projection transforms events into a read model. A query handler reads that model. These components may run in the same process or in separate processes.
Chronacta's responsibility
Chronacta stores event streams, checks expected versions, provides reads, and delivers events through subscriptions. It also provides built-in projection capabilities.
Application-side projections can build read models in other databases. Distinguish these consumers from projections executed by the Chronacta server.
Bounded contexts and integration
A bounded context defines the scope of a domain model and its language. It is not the same thing as an event stream or a server instance.
Define contracts when events cross context boundaries. Coordinate multi-step workflows in application components rather than treating the event store as a process manager.
Practical exercise
Draw the command handler, aggregate, repository, Chronacta, projection, and query handler. Identify who owns each contract and where failures must be handled.
Event Sourcing learning path · Previous · Next · Chronacta documentation
