Projections for gamification in a social app en

This is a rough idea, I'd definitely need to have a chat with you! ;-)

We have this company-internal social app where ppl. get 3 random cards with social tasks they need to finish to earn points, they can also reject a card once a week.
For gamification/envolvement/fun we have introduced "achievements", for some of them the players get extra points. E.g.: "first card of a deck" (cards are organized into different decks), 3rd task ever, 8th task ever, complete deck, ....

Interesting parts, apart from how cool projections are to create any sort of metric you invented while the app is already live, could be:
- how we implement that with EventStore DB with sucscriptions per "achievement" where we store commit checkpoints
- issues/open questions we just ran into which are based on the design at a point in time we did not know about "achievements" (not everything is possible/simple with ES)
- how much sanity checks, e.g. order of events, to do for such "view model" projections aka. how much should we trust our events?

Implementing an Event-Sourced Aggregate from scratch en

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)

Discovering Aggregate Implementation Patterns and Event-Sourcing via "Code Koans" en

There are many ways to implement the Aggregate pattern from Domain-Driven Design:

* OOP style or functional style
* Traditional or event-sourced
* Internal state, external state, on-the-fly state (reconstituted inside the aggregate)
* Reconstitute the full state or just the minimal state needed to make decisions
* Recording changes or returning changes

Many variations are possible, especially with event-sourced aggregates.
I really like the "event-sourced, minimal, on-the-fly state" combination which is a good fit for a prototype phase and is one of the variations in the workshop.

We will discover as many of those variations as possible during the workshop, but we will only implement the event-sourced ones because they are more interesting and allow more variants.

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!

If the workshop is only 2 hours:
* Everybody should be able to implement 3 variants (2 OOP, 3 functional) and the fast ppl. can do No. 4 (functional) as a bonus challenge
* We might have 10-15 minutes to answer questions, which - by experience - are often about persistence, CQRS, EDA, Kafka, ...

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

If the conference 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 conference is live and allows good separation of the participants:
* We offer that the participants work as teams, pairs, or solo

If the conference 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.

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

What is Event-Sourcing and how is it related to CQRS and Event-Driven Architecture (EDA) en de

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.

Was ist Event-Sourcing und wie verhält es sich zu CQRS und Event-Driven Architecture (EDA)? en de

Mit der steigenden Popularität von Event-Sourcing, CQRS und EDA entsteht einiges an Verwirrung zwischen diesen orthogonalen Konzepten, die sehr nützlich sind aber klar abgegrenzt werden sollten.

1) Zunächst werfen wir einen Blick auf jedes dieser Konzept im Einzelnen und wie sie zusammen benutzt werden können.

2) Danach werden wir im hands-on Teil einige verschiedene Patterns zur Implementierung von event-sourced Aggregates kennenlernen. Die Teilnehmer werden verschiedene Versionen des gleichen Aggregats im Stile von "Code Koans" implementieren. Für jede Variante sind die Test-Fälle schon vorgegeben, ebenso wie ein Skelett der Implementierung, das mit dem fehlenden Code gefüllt werden muss, damit die Tests grün werden.

Was die Teilnehmer dabei (kennen)lernen:
* Verschiedene Stile, um ein Aggregate zu implementieren
* Wie man das Konzept eines Aggregates ohne ein großes "Objekt" implementieren kann
* Die Basics des Event-Sourcing
* Eine light Version von Ensemble (Mob) Programming oder Pair-Programming
* Die Idee der "Code Koans"

Wir stellen Git Repositories zur Verfügung, die Java-, Kotlin-, C# und PHP Code enthalten:
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

Die Teilnehmer brauchen einen Laptop mit einer IDE, mit der sie in einer dieser Sprachen entwickeln können.
Idealerweise sollten sie den Code schon vor dem Workshop auschecken und die Abhängigkeiten installieren, so dass die Unit Test bereits laufen.

3) Schließlich werden wir uns den Q Teil von CQRS anschauen und mindestens eine "Projection" für ein(en) query/read-model/view implementieren. Die Teilnehmer können ihre Ideen einbringen und sich read-models ausdenken, die sie interessant finden.

4) Zeit für weitere Fragen und Antworten

Es handelt sich um einen Ganztags-Workshop, der teilweise flexibel gehalten werden kann:

Bei einer Länge von 6-7 Stunden:
* Alle Teilnehmer sollten in der Lage sein, 4 Varianten zu implementieren, von "typischen" OOP zu "functional"
* Wir sollten mindestens 20-30 Minuten für Fragen&Antworten haben

Bei einer Länge von 4-5 Stunden werden wir alle 4 Teile so weit wie nötig kürzen, aber weiterhin das komplette Bild vermitteln.

Falls der Workshop remote stattfindet:
* Teilen wir die Teilnehmer in Teams auf (idealerweise nicht mehr als 4), um sie mit 2 Trainern ausreichend unterstützen zu können
* Jedes Team wird als Ensemble (Mob) arbeiten und die "Driver" Rolle bei jeder Variante tauschen

Wenn der Workshop live stattfindet und eine gute Aufteilung der Teilnehmer erlaubt:
* Wir überlassen den Teilnehmern, ob sie als Team, Pair oder solo arbeiten wollen

Wenn der Workshop live stattfindet, aber der Raum recht klein ist:
* Wir überlassen den Teilnehmern, ob sie als Pair oder solo arbeiten wollen

Remote bevorzugen wir bis zu 20 Teilnehmer, maximal 24.
Live können wir mit bis zu 30 Teilnehmern arbeiten, 26 wäre ideal.

Remote benötigen wir ein Tool wie Zoom (mit Breakout Session).
Live brauchen wir eine großen Bildschirm oder einen Beamer.

Teil 2) dieses Workshops ist "rock solid", wir haben ihn erfolgreich und mit gutem Feedback bereits in unterschiedlichen Varianten gehalten:
* KandDDDinsky Okt/Nov 2022 (kandddinsky.de) - live (ein Raum, ca. 18 Teilnehmer)
* DDD Europe 06/2022 (dddeurope.com) - live (ein Raum, ca. 26 Teilnehmer)
* DDD Summit 11/2021 (ddd-summit.de) - remote (in 4 Teams aufgeteilt, ca.20+ Teilnehmer)
* DDD Europe 02/2021 (dddeurope.com) - remote (in 4 Teams aufgeteilt, ca.20 Teilnehmer)
* OOP Digital 02/2021 (www.oop-konferenz.de) - remote (in 4 Teams aufgeteilt, ca.20 Teilnehmer)
* DDD Summit 11/2020 (ddd-summit.de) - remote (in 4 Teams aufgeteilt, ca.20+ Teilnehmer)
* DDD Summit 06/2020 (ddd-summit.de) - remote (in 4 Teams aufgeteilt, ca.20+ Teilnehmer)
* Mehrmals innerhalb unserer Firma, mit kleineren Gruppen, remote

Der komplette Workshop mit den zusätzlichen Teilen 1) und 3) wurde bisher einmal für einen externen Kunden mit 6 Teilnehmern gehalten.