With the recent popularity of Event-Sourcing, CQRS, and EDA there is a lot of confusion between those orthogonal concepts, which are very useful but should be cleanly separated.

1) We'll first look at each of those concepts separately and how they can be used together.

2) After that, we will do a hands-on part to discover some different implementation patterns for event-sourced aggregates. Attendees will implement different versions of the same aggregate in a "Code Koans" fashion. For each variation, there will be test cases and a skeleton that has to be filled with the missing code to make the tests green.

What you will discover:
* Different styles of implementing an Aggregate
* How you can implement a conceptual Aggregate without having a big "object"
* The basics of event-sourcing
* A light version of ensemble (mob) programming or pair programming
* The idea of "Code Koans"

We supply Git repositories containing Java, Kotlin, C#, and PHP code:
https://github.com/MaibornWolff/aggregate-implementation-patterns-java
https://github.com/MaibornWolff/aggregate-implementation-patterns-kotlin
https://github.com/klimisa/aggregate-implementation-patterns-csharp
https://github.com/jursimplicate/aggregate-implementation-patterns-php

Attendees need a laptop with an IDE that is suitable for one of those languages.
Ideally, they pull the repo before the workshop and install the dependencies, so that they can run the unit tests!

3) Finally we will dive into the Q part of CQRS by implementing at least one "projection" for a query/read-model/view, where the participants are free to contribute their own ideas about which interesting read-model they want to build.

4) Time for further questions and answers

This is a full day workshop with some flexibility:

If the workshop is 6-7 hours:
* Everybody should be able to implement 4 variants, moving from "typical" OOP to functional
* We should have at least 20-30 minutes for Q&A

If the workshop is 4-5 hours we will shorten all 4 parts as much as necessary but still deliver the full picture.

If the workshop is remote:
* We will split the audience into teams (ideally not more than 4) to be able to be supported by 2 trainers
* Each group will work as an ensemble (mob) and change the driver role for each variation

If the workshop is live and allows good separation of the participants:
* We offer that the participants work as teams, pairs, or solo

If the workshop is live but the room is rather small:
* We offer that the participants work in pairs or solo

Remote we prefer to have 20 participants, max. 24.
Live we can do up to 30 but around 26 is preferred.

Remote we need a tool like Zoom to do the workshop.
Live we need a big TV or beamer to present our content.

Part 2) of this workshop is rock solid, we have done it with great success and feedback in different versions:
* KandDDDinsky Oct/Nov 2022 (kandddinsky.de) - live (one room, around 18 participants)
* DDD Europe 06/2022 (dddeurope.com) - live (one room, around 26 participants)
* DDD Summit 11/2021 (ddd-summit.de) - remote (split into 4 teams, around 20+ participants)
* DDD Europe 02/2021 (dddeurope.com) - remote (split into 4 teams, around 20 participants)
* OOP Digital 02/2021 (www.oop-konferenz.de) - remote (split into 4 teams, around 20 participants)
* DDD Summit 11/2020 (ddd-summit.de) - remote (split into 4 teams, around 20+ participants)
* DDD Summit 06/2020 (ddd-summit.de) - remote (split into 4 teams, around 20+ participants)
* Multiple times inside of our company, with smaller groups, remote

The whole workshop with additional parts 1) and 3) was done for an external client once, with 6 participants.