Event-Sourcing has gotten a lot of traction in the last couple of years, probably also through the recent success of Domain-Driven Design. In itself, it is a very old approach though, to record the changes of an entity instead of its current state - and then project the current state as a left fold of this stream of changes (Events). The main principle is used e.g. for ledgers, bank accounts, bin-logs of databases, and GIT.

Not only does it enable us to understand how an entity got into its current state. We can also project multiple different models from the same stream of events. Another important feature is the dimension of time, which is contained in the event stream. It enables us to project into so-called temporal models, for example, monthly reports for business intelligence or dynamic expiration of confirmation links we have emailed to a customer.

An often overlooked superpower of Event-Sourcing is the ability to change the model (its structure/implementation) any time without complicated database migrations. On the query/read model/view side of CQRS, it's possible to add new views whenever they are needed. We implement a new BI report and replay all events of a stream to populate it - done.

Sadly, the internet is full of confusing or delusive information and stories about how Event-Sourcing or CQRS projects failed or how complicated this approach is. In our workshop, you will find out that the basic principle might be unfamiliar but is less complicated than many enterprise patterns you probably have used in the past.

Talking about CQRS: Event-Sourcing is hardly possible without it, given any views are needed in the implementation. Therefore, we will explain the basic concept of CQRS, how it decouples command and query needs and gives us separation of concerns and simpler services that can change and scale independently.

During the workshop, we will implement an Event-Sourced Aggregate from the ground up, which includes a couple of Value Objects, Commands, and certainly some Domain Events. We will work test-driven for most parts. Unfortunately, using or implementing an EventStore is out of scope for this workshop due to time constraints.

We will learn the ropes by solving a problem with our Event-Sourced Aggregate based on the result of an EventStorming session.

In our session, we will share some common mistakes as well as some from previous projects. We will talk about pitfalls like event versioning. And lastly, we will address one of the most common newbie questions - "But isn't Event-Sourcing slow?" - by explaining some techniques for memoization (e.g. taking snapshots, identity maps, ....) - and why they are often not needed at all.

Requirements

To attend this workshop you should have a basic understanding of tactical Domain-Driven Design concepts: Value Objects, Commands, Domain Events, and Entities / Aggregates. Never mind, if you don't fully understand what constitutes an Aggregate, it's secondary for understanding Event-Sourcing. Nevertheless, we will be able to provide an explanation.

The workshop is programming language agnostic! Just bring your laptop with your favorite development environment and a framework to run Unit Tests or Behavioral tests.

The coaches are fluent in Golang, Java, C#, and PHP, but any other programming language is also fine.

I need a beamer and ideally a table.
Target audience are beginners or advanced beginners in Event-Sourcing.
The preferred session duration is 6 - 7 hours.
Max amount of attendees is 10 (if I host it alone) or 20 (if I bring a co-host).

This workshop was done at:
* API, Microservices and DDD Summit, June 2020 (remote)
* 2 times at our company MaibornWolff (1 x in person, 1 x remote)