Tutorial, practical samples and other resources about Event Sourcing in .NET Core.

• EventSourcing.NetCore
  • 1. Event Sourcing
    • 1.1 What is Event Sourcing?
    • 1.2 What is Event?
    • 1.3 What is Stream?
    • 1.4 Event representation
    • 1.5 Event Storage
    • 1.6 Retrieving the current state from events
  • 2. Support
  • 3. Prerequisites
  • 4. Libraries used
  • 5. Articles
  • 6. Event Store - Marten
  • 7. Message Bus (for processing Commands, Queries, Events) - MediatR
  • 8. CQRS (Command Query Responsibility Separation)
  • 9. Fully working sample application
  • 10. Self-paced training Kit
  • 11. NuGet packages to help you get started.
  • 12. Other resources
    • 12.1 Introduction
    • 12.2 Event Sourcing on production
    • 12.3 Projections
    • 12.4 Snapshots
    • 12.5 Versioning
    • 12.6 Storage
    • 12.7 Design & Modeling
    • 12.8 GDPR
    • 12.9 Conflict Detection
    • 12.10 Functional programming
    • 12.12 Testing
    • 12.13 CQRS
    • 12.14 Tools
    • 12.15 Event Sourcing vs Messaging
    • 12.15 Event processing
    • 12.16 Distributed processes
    • 12.17 Domain Driven Design
    • 12.18 Architecture Weekly

Event Sourcing is a design pattern in which results of business operations are stored as a series of events.

It is an alternative way to persist data. In contrast with state-oriented persistence that only keeps the latest version of the entity state, Event Sourcing stores each state change as a separate event.

Thanks for that, no business data is lost. Each operation results in the event stored in the database. That enables extended auditing and diagnostics capabilities (both technically and business-wise). What's more, as events contains the business context, it allows wide business analysis and reporting.

In this repository I'm showing different aspects, patterns around Event Sourcing. From the basic to advanced practices.

Read more in my article:

• 📝 How using events helps in a teams' autonomy

Events, represent facts in the past. They carry information about something accomplished. It should be named in the past tense, e.g. "user added", "order confirmed". Events are not directed to a specific recipient - they're broadcasted information. It's like telling a story at a party. We hope that someone listens to us, but we may quickly realise that no one is paying attention.

Events:

• are immutable: "What has been seen, cannot be unseen".
• can be ignored but cannot be retracted (as you cannot change the past).
• can be interpreted differently. The basketball match result is a fact. Winning team fans will interpret it positively. Losing team fans - not so much.

Read more in my articles:

• 📝 What's the difference between a command and an event?
• 📝 Events should be as small as possible, right?

Events are logically grouped into streams. In Event Sourcing, streams are the representation of the entities. All the entity state mutations ends up as the persisted events. Entity state is retrieved by reading all the stream events and applying them one by one in the order of appearance.

A stream should have a unique identifier representing the specific object. Each event has its own unique position within a stream. This position is usually represented by a numeric, incremental value. This number can be used to define the order of the events while retrieving the state. It can be also used to detect concurrency issues.

Technically events are messages.

They may be represented, e.g. in JSON, Binary, XML format. Besides the data, they usually contain:

• id: unique event identifier.
• type: name of the event, e.g. "invoice issued".
• stream id: object id for which event was registered (e.g. invoice id).
• stream position (also named version, order of occurrence, etc.): the number used to decide the order of the event's occurrence for the specific object (stream).
• timestamp: representing a time at which the event happened.
• other metadata like correlation id, causation id, etc.

Sample event JSON can look like:

{
  "id": "e44f813c-1a2f-4747-aed5-086805c6450e",
  "type": "invoice-issued",
  "streamId": "INV/2021/11/01",
  "streamPosition": 1,
  "timestamp": "2021-11-01T00:05:32.000Z",

  "data":
  {
    "issuedTo": {
      "name": "Oscar the Grouch",
      "address": "123 Sesame Street",
    },
    "amount": 34.12,
    "number": "INV/2021/11/01",
    "issuedAt": "2021-11-01T00:05:32.000Z"
  },

  "metadata": 
  {
    "correlationId": "1fecc92e-3197-4191-b929-bd306e1110a4",
    "causationId": "c3cf07e8-9f2f-4c2d-a8e9-f8a612b4a7f1"
  }
}

Event Sourcing is not related to any type of storage implementation. As long as it fulfils the assumptions, it can be implemented having any backing database (relational, document, etc.). The state has to be represented by the append-only log of events. The events are stored in chronological order, and new events are appended to the previous event. Event Stores are the databases' category explicitly designed for such purpose.

Read more in my article:

• 📝 What if I told you that Relational Databases are in fact Event Stores?

In Event Sourcing, the state is stored in events. Events are logically grouped into streams. Streams can be thought of as the entities' representation. Traditionally (e.g. in relational or document approach), each entity is stored as a separate record.

In Event Sourcing, the entity is stored as the series of events that happened for this specific object, e.g. InvoiceInitiated, InvoiceIssued, InvoiceSent.

[
    {
        "id": "e44f813c-1a2f-4747-aed5-086805c6450e",
        "type": "invoice-initiated",
        "streamId": "INV/2021/11/01",
        "streamPosition": 1,
        "timestamp": "2021-11-01T00:05:32.000Z",

        "data":
        {
            "issuer": {
                "name": "Oscar the Grouch",
                "address": "123 Sesame Street",
            },
            "amount": 34.12,
            "number": "INV/2021/11/01",
            "initiatedAt": "2021-11-01T00:05:32.000Z"
        }
    },        
    {
        "id": "5421d67d-d0fe-4c4c-b232-ff284810fb59",
        "type": "invoice-issued",
        "streamId": "INV/2021/11/01",
        "streamPosition": 2,
        "timestamp": "2021-11-01T00:11:32.000Z",

        "data":
        {
            "issuedTo": "Cookie Monster",
            "issuedAt": "2021-11-01T00:11:32.000Z"
        }
    },        
    {
        "id": "637cfe0f-ed38-4595-8b17-2534cc706abf",
        "type": "invoice-sent",
        "streamId": "INV/2021/11/01",
        "streamPosition": 3,
        "timestamp": "2021-11-01T00:12:01.000Z",

        "data":
        {
            "sentVia": "email",
            "sentAt": "2021-11-01T00:12:01.000Z"
        }
    }
]

All of those events shares the stream id ("streamId": "INV/2021/11/01"), and have incremented stream position.

We can get to conclusion that in Event Sourcing entity is represented by stream, so sequence of event correlated by the stream id ordered by stream position.

To get the current state of entity we need to perform the stream aggregation process. We're translating the set of events into a single entity. This can be done with the following the steps:

1. Read all events for the specific stream.
2. Order them ascending in the order of appearance (by the event's stream position).
3. Construct the empty object of the entity type (e.g. with default constructor).
4. Apply each event on the entity.

This process is called also stream aggregation or state rehydration.

We could implement that as:

public record Person(
    string Name,
    string Address
);

public record InvoiceInitiated(
    double Amount,
    string Number,
    Person IssuedTo,
    DateTime InitiatedAt
);

public record InvoiceIssued(
    string IssuedBy,
    DateTime IssuedAt
);

public enum InvoiceSendMethod
{
    Email,
    Post
}

public record InvoiceSent(
    InvoiceSendMethod SentVia,
    DateTime SentAt
);

public enum InvoiceStatus
{
    Initiated = 1,
    Issued = 2,
    Sent = 3
}

public class Invoice
{
    public string Id { get;set; }
    public double Amount { get; private set; }
    public string Number { get; private set; }

    public InvoiceStatus Status { get; private set; }

    public Person IssuedTo { get; private set; }
    public DateTime InitiatedAt { get; private set; }

    public string IssuedBy { get; private set; }
    public DateTime IssuedAt { get; private set; }

    public InvoiceSendMethod SentVia { get; private set; }
    public DateTime SentAt { get; private set; }

    public void When(object @event)
    {
        switch (@event)
        {
            case InvoiceInitiated invoiceInitiated:
                Apply(invoiceInitiated);
                break;
            case InvoiceIssued invoiceIssued:
                Apply(invoiceIssued);
                break;
            case InvoiceSent invoiceSent:
                Apply(invoiceSent);
                break;
        }
    }

    private void Apply(InvoiceInitiated @event)
    {
        Id = @event.Number;
        Amount = @event.Amount;
        Number = @event.Number;
        IssuedTo = @event.IssuedTo;
        InitiatedAt = @event.InitiatedAt;
        Status = InvoiceStatus.Initiated;
    }

    private void Apply(InvoiceIssued @event)
    {
        IssuedBy = @event.IssuedBy;
        IssuedAt = @event.IssuedAt;
        Status = InvoiceStatus.Issued;
    }

    private void Apply(InvoiceSent @event)
    {
        SentVia = @event.SentVia;
        SentAt = @event.SentAt;
        Status = InvoiceStatus.Sent;
    }
}

and use it as:

var invoiceInitiated = new InvoiceInitiated(
    34.12,
    "INV/2021/11/01",
    new Person("Oscar the Grouch", "123 Sesame Street"),
    DateTime.UtcNow
);
var invoiceIssued = new InvoiceIssued(
    "Cookie Monster",
    DateTime.UtcNow
);
var invoiceSent = new InvoiceSent(
    InvoiceSendMethod.Email,
    DateTime.UtcNow
);

// 1,2. Get all events and sort them in the order of appearance
var events = new object[] {invoiceInitiated, invoiceIssued, invoiceSent};

// 3. Construct empty Invoice object
var invoice = new Invoice();

// 4. Apply each event on the entity.
foreach (var @event in events)
{
    invoice.When(@event);
}

and generalise this into Aggregate base class:

public abstract class Aggregate<T>
{
    public T Id { get; protected set; }
    
    protected Aggregate() { }
        
    public virtual void When(object @event) { }
}

The biggest advantage of "online" stream aggregation is that it always uses the most recent business logic. So after the change in the apply method, it's automatically reflected on the next run. If events data is fine, then it's not needed to do any migration or updates.

In Marten When method is not needed. Marten uses naming convention and call the Apply method internally. It has to:

• have single parameter with event object,
• have void type as the result.

See full details in the:

• Generic stream aggregation example
• Marten

Feel free to create an issue if you have any questions or request for more explanation or samples. I also take Pull Requests!

💖 If this repository helped you - I'd be more than happy if you join the group of my official supporters at:

👉 Github Sponsors

For running the Event Store examples you need to have:

1. .NET 5 installed - https://dotnet.microsoft.com/download/dotnet/5.0
2. Postgres DB. You can get it by:

• Installing Docker, going to the docker folder and running:

docker-compose up

• Installing a most recent version of the Postgres DB (eg. from https://www.postgresql.org/download/).

More information about using .NET Core, WebApi and Docker you can find in my other tutorials: WebApi with .NET

You can also watch my presentation "Practical Event Sourcing with Marten":

1. Marten - Event Store

2. MediatR - Message Bus (for processing Commands, Queries, Events)

Read also more on the Event Sourcing and CQRS topics in my blog posts:

• 📝 What's the difference between a command and an event?
• 📝 Events should be as small as possible, right?
• 📝 Why a bank account is not the best example of Event Sourcing?
• 📝 How using events helps in a teams' autonomy
• 📝 How to (not) do the events versioning?
• 📝 CQRS facts and myths explained
• 📝 Can command return a value?
• 📝 How to create projections of events for nested object structures?
• 📝 What texting your Ex has to do with Event-Driven Design?
• 📝 What if I told you that Relational Databases are in fact Event Stores?
• 📝 Optimistic concurrency for pessimistic times
• 📝 Outbox, Inbox patterns and delivery guarantees explained
• 📝 Saga and Process Manager - distributed processes in practice

Slides:

• 👨🏼‍🏫 Practical Event Sourcing with Marten - EN, PL
• 👨🏼‍🏫 Ligths and Shades of Event-Driven Design - EN, PL
• 👨🏼‍🏫 Adventures in Event Sourcing and CQRS - PL

• Creating event store
• Event Stream - is a representation of the entity in event sourcing. It's a set of events that happened for the entity with the exact id. Stream id should be unique, can have different types but usually is a Guid.
  • Stream starting - stream should be always started with a unique id. Marten provides three ways of starting the stream:
    • calling StartStream method with a stream id

      var streamId = Guid.NewGuid();
      documentSession.Events.StartStream<IssuesList>(streamId);

    • calling StartStream method with a set of events

      var @event = new IssueCreated { IssueId = Guid.NewGuid(), Description = "Description" };
      var streamId = documentSession.Events.StartStream<IssuesList>(@event);

    • just appending events with a stream id

      var @event = new IssueCreated { IssueId = Guid.NewGuid(), Description = "Description" };
      var streamId = Guid.NewGuid();
      documentSession.Events.Append(streamId, @event);

  • Stream loading - all events that were placed on the event store should be possible to load them back. Marten allows to:
    • get list of event by calling FetchStream method with a stream id

      var eventsList = documentSession.Events.FetchStream(streamId);

    • geting one event by its id

      var @event = documentSession.Events.Load<IssueCreated>(eventId);

  • Stream loading from exact state - all events that were placed on the event store should be possible to load them back. Marten allows to get stream from exact state by:
    • timestamp (has to be in UTC)

      var dateTime = new DateTime(2017, 1, 11);
      var events = documentSession.Events.FetchStream(streamId, timestamp: dateTime);

    • version number

      var versionNumber = 3;
      var events = documentSession.Events.FetchStream(streamId, version: versionNumber);

• Event stream aggregation - events that were stored can be aggregated to form the entity once again. During the aggregation, process events are taken by the stream id and then replied event by event (so eg. NewTaskAdded, DescriptionOfTaskChanged, TaskRemoved). At first, an empty entity instance is being created (by calling default constructor). Then events based on the order of appearance are being applied on the entity instance by calling proper Apply methods.
  • Online Aggregation - online aggregation is a process when entity instance is being constructed on the fly from events. Events are taken from the database and then aggregation is being done. The biggest advantage of online aggregation is that it always gets the most recent business logic. So after the change, it's automatically reflected and it's not needed to do any migration or updates.
  • Inline Aggregation (Snapshot) - inline aggregation happens when we take the snapshot of the entity from the DB. In that case, it's not needed to get all events. Marten stores the snapshot as a document. This is good for performance reasons because only one record is being materialized. The con of using inline aggregation is that after business logic has changed records need to be reaggregated.
  • Reaggregation - one of the biggest advantages of the event sourcing is flexibility to business logic updates. It's not needed to perform complex migration. For online aggregation it's not needed to perform reaggregation - it's being made always automatically. The inline aggregation needs to be reaggregated. It can be done by performing online aggregation on all stream events and storing the result as a snapshot.
    • reaggregation of inline snapshot with Marten

      var onlineAggregation = documentSession.Events.AggregateStream<TEntity>(streamId);
      documentSession.Store<TEntity>(onlineAggregation);
      documentSession.SaveChanges();

• Event transformations
  • One event to one object transformations
  • Inline Transformation storage
• Events projection
  • Projection of single stream
• Multitenancy per schema

• Initialization - MediatR uses services locator pattern to find a proper handler for the message type.
• Sending Messages - finds and uses the first registered handler for the message type. It could be used for queries (when we need to return values), commands (when we acting).
  • No Handlers - when MediatR doesn't find proper handler it throws an exception.
  • Single Handler - by implementing IRequestHandler we're deciding that this handler should be run asynchronously with other async handlers (so we don't wait for the previous handler to finish its work).
  • More Than One Handler - when there is more than one handler registered MediatR takes only one ignoring others when Send method is being called.
• Publishing Messages - finds and uses all registered handlers for the message type. It's good for processing events.
  • No Handlers - when MediatR doesn't find proper handler it throws an exception
  • Single Handler - by implementing INotificationHandler we're deciding that this handler should be run asynchronously with other async handlers (so we don't wait for the previous handler to finish its work)
  • More Than One Handler - when there is more than one handler registered MediatR takes all of them when calling Publish method
• Pipeline (to be defined)

• Command handling
• Query handling

See also fully working sample application in Sample Project

• See sample how Entity Framework and Marten can coexist together with CQRS and Event Sourcing

I prepared the self-paced training Kit for the Event Sourcing. See more in the Workshop description.

It's split into two parts:

Event Sourcing basics - it teaches the event store basics by showing how to build your Event Store on Relational Database. It starts with the tables setup, goes through appending events, aggregations, projections, snapshots, and finishes with the Marten basics. See more in here.

1. Streams Table
2. Events Table
3. Appending Events
4. Optimistic Concurrency Handling
5. Event Store Methods
6. Stream Aggregation
7. Time Travelling
8. Aggregate and Repositories
9. Snapshots
10. Projections
11. Projections With Marten

Event Sourcing advanced topics - it's a real-world sample of the microservices written in Event-Driven design. It explains the topics of modularity, eventual consistency. Shows practical usage of WebApi, Marten as Event Store, Kafka as Event bus and ElasticSearch as one of the read stores. See more in here.

1. Meetings Management Module - the module responsible for creating, updating meeting details. Written in Marten in Event Sourcing pattern. Provides both write model (with Event Sourced aggregates) and read model with projections.
2. Meetings Search Module - responsible for searching and advanced filtering. Uses ElasticSearch as storage (because of its advanced searching capabilities). It's a read module that's listening for the events published by the Meetings Management Module.

I gathered and generalized all of the practices used in this tutorial/samples in Nuget Packages maintained by me GoldenEye Framework. See more in:

• GoldenEye DDD package - it provides a set of base and bootstrap classes that helps you to reduce boilerplate code and help you focus on writing business code. You can find all classes like Commands/Queries/Event handlers and many more. To use it run:

  dotnet add package GoldenEye.Backend.Core.DDD

• GoldenEye Marten package - contains helpers, and abstractions to use Marten as document/event store. Gives you abstractions like repositories etc. To use it run:

  dotnet add package GoldenEye.Backend.Core.Marten

The simplest way to start is installing the project template by running

dotnet new -i GoldenEye.WebApi.Template.SimpleDDD

and then creating a new project based on it:

dotnet new SimpleDDD -n NameOfYourProject

• 📝 Event Store - A Beginner’s Guide to Event Sourcing
• 🎞 Greg Young - CQRS & Event Sourcing
• 📝 Jay Kreps - Why local state is a fundamental primitive in stream processing
• 📝 Microsoft - Exploring CQRS and Event Sourcing
• 📰 Lorenzo Nicora - A visual introduction to event sourcing and cqrs
• 🎞 Mathew McLoughlin - An Introduction to CQRS and Event Sourcing Patterns
• 🎞 Emily Stamey - Hey Boss, Event Sourcing Could Fix That!
• 🎞 Derek Comartin - Event Sourcing Example & Explained in plain English
• 🎞 Duncan Jones - Introduction to event sourcing and CQRS
• 🎞 Roman Sachse - Event Sourcing - Do it yourself series
• 🎞 Martin Fowler - The Many Meanings of Event-Driven Architecture
• 📝 Martin Fowler - Event Sourcing
• 📝 Dennis Doomen - 16 design guidelines for successful Event Sourcing
• 🎞 Martin Kleppmann - Event Sourcing and Stream Processing at Scale
• 📝 Dennis Doomen - The Good, The Bad and the Ugly of Event Sourcing
• 🎞 Alexey Zimarev - DDD, Event Sourcing and Actors
• 🎞 Thomas Bøgh Fangel - Event Sourcing: Traceability, Consistency, Correctness
• 📝 Joseph Choe - Event Sourcing, Part 1: User Registration
• 🎞 Steven Van Beelen - Intro to Event-Driven Microservices using DDD, CQRS & Event sourcing
• 📝 Yves Lorphelin - The Inevitable Event-Centric Book

• 📝 Leo Gorodinski - Scaling Event-Sourcing at Jet
• 📝 EventStoreDB - Customers' case studies
• 🎞 P. Avery, R. Reta - Scaling Event Sourcing for Netflix Downloads
• 📝 M. Overeem, M. Spoor, S. Jansen, S. Brinkkemper - An Empirical Characterization of Event Sourced Systems and Their Schema Evolution -- Lessons from Industry
• 🎞 Michiel Overeem - Event Sourcing after launch
• 🎞 Greg Young - A Decade of DDD, CQRS, Event Sourcing
• 📝 M. Kadijk, J. Taal - The beautiful headache called event sourcing
• 📝 Thomas Weiss - Planet-scale event sourcing with Azure Cosmos DB
• 🎞 D. Kuzenski, N. Piani - Beyond APIs: Re-architected System Integrations as Event Sourced
• 🎞 Greg Young - Why Event Sourced Systems Fail
• 🎞 Kacper Gunia - War Story: How a Large Corporation Used DDD to Replace a Loyalty System
• 🎞 Vladik Khononov - The Dark Side of Events
• 📝 Pedro Costa - Migrating to Microservices and Event-Sourcing: the Dos and Dont’s
• 🎞 Dennis Doomen - An Event Sourcing Retrospective - The Good, The Bad and the Ugly
• 🎞 David Schmitz - Event Sourcing You are doing it wrong
• 📝 Dennis Doomen - A recipe for gradually migrating from CRUD to Event Sourcing

• 📝 Alexey Zimarev - Projections in Event Sourcing
• 📝 Rinat Abdulin - Event Sourcing - Projections
• 🎞 Derek Comartin - Projections in Event Sourcing: Build ANY model you want!

• 📝 Kacper Gunia - Event Sourcing: Snapshotting
• 🎞 Derek Comartin - Event Sourcing: Rehydrating Aggregates with Snapshots

• 📝 Greg Young - Versioning in an Event Sourced System
• 📝 Kacper Gunia - Event Sourcing: Snapshotting
• 📝 M. Overeem, M. Spoor - The dark side of event sourcing: Managing data conversion
• 📝 Savvas Kleanthous - Event immutability and dealing with change
• 📝 Versioning in an Event Sourced System

• 📝 Greg Young - Building an Event Storage
• 🎞 Andrii Litvinov - Event driven systems backed by MongoDB
• 📝 Dave Remy - Turning the database inside out with Event Store

• 📝 Mathias Verraes - DDD and Messaging Architectures
• 📝 David Boike - Putting your events on a diet
• 🎞 Thomas Pierrain - As Time Goes By… (a Bi-temporal Event Sourcing story)
• 📝 Vaughn Vernon - Effective Aggregate Design Part I: Modeling a Single Aggregate
• 🎞 Derek Comartin - Aggregate (Root) Design: Separate Behavior & Data for Persistence
• 🎞 Mauro Servienti - All our aggregates are wrong
• 📝 Microsoft - Domain events: design and implementation
• 📝 Event Storming
• 📝 Event Modeling
• 📝 Wojciech Suwała - Building Microservices On .NET Core – Part 5 Marten An Ideal Repository For Your Domain Aggregates

• 📝 Michiel Rook - Event sourcing and the GDPR: a follow-up

• 🎞 James Geall - Conflict Detection and Resolution in an EventSourced System
• 🎞 Lightbend - Data modelling for Replicated Event Sourcing
• 📰 Bartosz Sypytkowski - Collaborative Event Sourcing

• 📝 Jérémie Chassaing - Functional Programming and Event Sourcing

• 🎞 N. Rauch & A. Bailly - From Front to Back: Homomorphic Event Sourcing

• 📝 Greg Young - CQRS
• 📝 Jimmy Bogard - CQRS and REST: the perfect match
• 📝 Mark Seemann - CQS versus server-generated IDs
• 📝 Julie Lerman - Data Points - CQRS and EF Data Models
• 📝 Marco Bürckel - Some thoughts on using CQRS without Event Sourcing
• 📝 Bertrand Meyer - Eiffel: a language for software engineering (CQRS introduced)

• 🛠️ Marten - .NET Transactional Document DB and Event Store on PostgreSQL
• 🛠️ EventStoreDB - The stream database built for Event Sourcing
• 🛠️ GoldenEye - The CQRS flavoured framework that will speed up your WebAPI and Microservices development
• 🛠️ Eventuous - Event Sourcing for .NET
• 🛠️ SQLStreamStore - Stream Store library targeting RDBMS based implementations for .NET
• 🛠️ Equinox - .NET Event Sourcing library with CosmosDB, EventStoreDB, SqlStreamStore and integration test backends

• 📝 Kacper Gunia - EventStoreDB vs Kafka
• 📝 Vijay Nair - Axon and Kafka - How does Axon compare to Apache Kafka?

• 📝 Kamil Grzybek - The Outbox Pattern
• 🎞 Dev Mentors - Inbox & Outbox pattern - transactional message processing
• 📝 Jeremy D. Miller - Jasper's "Outbox" Pattern Support
• 📝 Gunnar Morling - Reliable Microservices Data Exchange With the Outbox Pattern
• 📝 Microsoft - Asynchronous message-based communication
• 📝 NServiceBus - Outbox
• 📝 Alvaro Herrera - Implement SKIP LOCKED for row-level locks

• 📝 Hector Garcaa-Molrna, Kenneth Salem - Sagas
• 🎞 Caitie McCaffrey - Applying the Saga Pattern
• 🎞 Udi Dahan - If (domain logic) then CQRS or Saga?
• 🎞 Gregor Hohpe - Starbucks Does Not Use Two-Phase Commit
• 📝 Microsoft - Design Patterns - Saga distributed transactions pattern
• 📝 Microsoft - Design Patterns - Choreography
• 🎞 Martin Schimak - Know the Flow! Events, Commands & Long-Running Services
• 📝 Martin Schimak - Aggregates and Sagas are Processes
• 🎞 Chris Richardson - Using sagas to maintain data consistency in a microservice architecture
• 📝 Thanh Le - What is SAGA Pattern and How important is it?
• 📝 Jimmy Bogard - Life Beyond Distributed Transactions: An Apostate's Implementation - Relational Resources
• 📝 Rinat Abdullin - Evolving Business Processes
• 📝 Microsoft - A Saga on Sagas
• 📝 NServiceBus - Sagas
• 📝 NServiceBus sagas: Integrations
• 📝 Denis Rosa (Couchbase) - Saga Pattern | Application Transactions Using Microservices

• 📝 Eric Evans - DDD and Microservices: At Last, Some Boundaries!
• 📖 Domain-Driven Design: The First 15 Years
• 🎞 Jimmy Bogard - Domain-Driven Design: The Good Parts
• 💻 Jakub Pilimon - DDD by Examples
• 📖 DDD Quickly
• 📝 Vaughn Vernon - Reactive DDD: Modeling Uncertainty

If you're interested in Architecture resources, check my other repository: https://github.com/oskardudycz/ArchitectureWeekly/.

It contains a weekly updated list of materials I found valuable and educational.

EventSourcing.NetCore is Copyright © 2017-2021 Oskar Dudycz and other contributors under the MIT license.