A lightweight, opinionated CQRS and event sourcing framework targeting serverless architectures.
cqrs-es is available from Crates.io or Github.
cqrs-es = "0.0.18"
Documentation is available here along with an introduction to CQRS and event sourcing.
A demo application is available here.
- Event upcasters.
- Event serialization uses the event type as the root node of the JSON tree. This simplifies
deserialization but is non-standard.
- A persistence implementation for DynamoDb.
- A persistence implementation for MySql.
- Support for snapshots.
An in-memory event store suitable for local testing.
Test provides a test framework for building a resilient test base around aggregates.
TestFramework should be used to build a comprehensive set of aggregate tests to verify
your application logic (aka business rules).
This is the base framework for applying commands to produce events.
EventEnvelope is a data structure that encapsulates an event with along with it's pertinent
information. All of the associated data will be transported and persisted together.
Payload for an
AggregateError::UserError, somewhat modeled on the errors produced by the
validator package. This payload implements
with the intention of allowing the user to return this object as the response payload.
In CQRS (and Domain Driven Design) an
Aggregate is the fundamental component that
encapsulates the state and application logic (aka business rules) for the application.
Aggregate is always an entity along with all objects associated with it.
Command represents a request to modify the state of an
Aggregate by producing
DomainEvent represents any business change in the state of an
are immutable and with event sourcing
they are the source of truth.
The abstract central source for loading past events and committing new events.
Query is a read element in a CQRS system. As events are emitted multiple downstream queries
are updated to reflect the current state of the system. A query may also be referred to as a
'view', the concepts are identical but 'query' is used here to conform with CQRS nomenclature.
Each CQRS platform should have one or more
QueryProcessors where it will distribute committed
events, it is the responsibility of the
QueryProcessor to update any interested