If you liked my work and want to support me, please give it a star. Thanks!
This repository is a sandbox to experiment CQRS and Event Sourcing techniques.
docker-compose -f ./infra/docker-compose.yml -p event-sourcing up -d
localhost:8000/swagger
localhost:2113
CQRS stands for Command Query Responsibility Segregation. It's a pattern described by Greg Young. In short is the notion that you can use different models to write and read operations. The separation could be logic, segregating operations at application level, or with different databases for write and read operations.
In the case of the different databases approach, you should define a synchronization alternative. The must popular are: Eventual, in process with Unit of Work, OnDemand, and Scheduled.
"We can query an application's state to find out the current state of the world, and this answers many questions. However there are times when we don't just want to see where we are, we also want to know how we got there.
Event Sourcing ensures that all changes to application state are stored as a sequence of events. Not just can we query these events, we can also use the event log to reconstruct past states, and as a foundation to automatically adjust the state to cope with retroactive changes." Martin Fowler
For the app architecture I'm using a Clean Architecture model, splitting the solution into: Core for domain modeling and use cases, Infra for database, IoC, Integrations and other infrastructure concerns, Services for application entrypoint, and SharedKernel for base stuff.
The organization follows "The Screaming Architecture" concept by Uncle Bob that purposes that your application architecture should scream what the system does. So I've preferred an organization by context rather than by component type. Also the Use Cases are divided into Write or Read operations. Also, any Use Case has its owns Command, Query, Result, and Handler.
The application is containerized using Docker and automated using Docker Compose. I took the caution not to use default ports in containers to avoid conflict with other containers/servers that you may have using these ports.
- ASPNET.Core - Web Framework
- Dapper - Micro ORM
- Postgres - Read Database
- EventStorageDB - Events Storage
- Docker - Container Management
- Docker Compose - Multi-Container Management
- Mediatr - Use Cases Decoupling and Behaviours Pipelines
- FluentValidation - Data Validation
- MicrosoftPackages - Dependency Injection, In-Memory Database, and more