Crate cqrs_es2[−][src]
Expand description
cqrs-es2
A lightweight, opinionated CQRS and event sourcing framework targeting serverless architectures.
Installation
[dependencies]
cqrs-es2 = "0.4.0"
serde = { version = "^1.0.127", features = ["derive"] }
serde_json = "^1.0.66"Usage
Documentation is available here along with an introduction to CQRS and event sourcing.
Demo applications:
Modules
A simple memory store for testing purposes only
Test provides a test framework for building a resilient test base
around aggregates. A TestFramework should be used to build a
comprehensive set of aggregate tests to verify your application
logic (aka business rules).
Structs
Returns the aggregate and context around it that is needed when committing events in an event store implementation.
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 Serialize
with the intention of allowing the user to return this object as
the response payload.
Enums
The base error for the framework.
Traits
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. An Aggregate is
always an entity along with all objects associated with it.
A DomainCommand represents business API call.
A DomainEvent represents any business change in the state of an
Aggregate. DomainEvents are immutable and with event sourcing
they are the source of truth.
The abstract central source for loading past events and committing new events.
A 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 queries.