EventSourcing.NetCore Versions Save

• Simplest CQRS and Event Sourcing flow using Minimal API,
• Cutting the number of layers and boilerplate complex code to the bare minimum,
• Using all Marten helpers like WriteToAggregate and AggregateStream to simplify the processing,
• Examples of all the typical Marten's projections,
• Example of how and where to use C# Records, Nullable Reference Types, etc,
• No Aggregates. Commands are handled in the domain service as pure functions.

See more in https://github.com/oskardudycz/EventSourcing.NetCore/pull/161.

1. Migrated all API tests to Ogooreck.
2. Removed all startup classes and used a single Program file and WebApplicationFactory for tests.
3. Aligned tests, and removed obsolete helpers.
4. Fixed issue with doubled registration of event handlers because of open-generic EventListener registration (replaced with IEventBus decorator).

Read more about Ogooreck in my blog post: Ogooreck, a sneaky testing library in BDD style.

See details in PR: https://github.com/oskardudycz/EventSourcing.NetCore/pull/136.

1. Aligned also Marten projections naming to latest convention:

• AggregateProjection to SingleStreamAggregation,
• ViewProjection to MultiStreamAggregation

2. Used convention-based version assignment on stream aggregation and single-stream projections.

Fixed Kafka integration

• added the initialiser to docker-compose to set the Kafka topics upfront.
• fixed EventEnvelope creation to use a generic one. Changed the non-generic from record to interface to make sure that it won't be used.
• made sure that EventBus takes only EventEnvelope.
• created EventEnvelope in the external publishing.
• used handler in KafkaConsumer to deserialise contracts with private constructors,
• changed KafkaConsumer setting to commit offset manually.
• enforced EventEnvelope on in-memory bus.
• added EventEnvelopeExtensions for Kafka message deserialisation and aligned with EventStoreDB subscription to all to ignore messages that are not able to deserialise

See more in PR: https://github.com/oskardudycz/EventSourcing.NetCore/pull/150

Do you know that you can use .NET MinimalAPI methods not only in Program.cs? Yes, you can! It lets you slice your architecture and put endpoints definitions separately, near the respectful business logic. This matches great with CQRS.

See more in the PR: https://github.com/oskardudycz/EventSourcing.NetCore/pull/144

• CQRS flow using Minimal API,
• example how to inject handlers in MediatR'like style to decouple API from handling,
• example of how and where to use C# Records, Nullable Reference Types, etc,
• No Event Sourcing! Using Entity Framework to show that CQRS is not bounded to Event Sourcing or any type of storage,
• No Aggregates! CQRS does not need DDD. Business logic can be handled by handlers.
• 📝 Read more CQRS is simpler than you think with .NET 6 and C# 10

See more in

• code https://github.com/oskardudycz/EventSourcing.NetCore/tree/main/Sample/Warehouse.MinimalAPI
• PR https://github.com/oskardudycz/EventSourcing.NetCore/pull/92.

Refactored and added solutions projections exercises

Refactored projections tests to focus on single-stream projections first, then expand on multi-stream projections. Mixing them in the same exercise brings too many concepts immediately. I decided to refactor the current one to show details and list projections for the single stream and include multi-stream projections as the follow-up exercises. They will come in one of the following pull requests.

See the new version of the exercises:

• projections,
• projections with idempotency handling,
• projections with eventual consistency handling.

Related Pull Requests: #139 , #140

Added link to "CQRS is simpler than you think with C#9 and NET 5!" webinar

Watch it 👇

Added link to "How to deal with privacy and GDPR in Event-Sourced systems" talk. Watch it 👇

Upgraded also packages to the most recent versions.

Added link to "Let's build the worst Event Sourcing system!" talk I gave at EventSourcing Live 2021 conference. Watch it 👇