DDD mit Event Sourcing: So baust du Aggregate, die nicht explodieren

Dieses riesige User-Model in deiner App? Das ist ein Gott-Objekt und es wird
dir den Tag versauen. Lass uns das mit ordentlichem DDD und Event Sourcing
fixen.

Einleitung: Das unvermeidliche Gott-Objekt
Teil 1: Der wahre Job des Aggregat-Roots (Er ist ein Türsteher)
Teil 2: Das Gott-Aggregat killen
Deine Logik testen (ohne Datenbank)
Fazit

Einleitung: Das unvermeidliche Gott-Objekt

Wir haben es alle schon getan. Ein Projekt fängt einfach an. Du hast eine
User-Entity. Dann braucht der User ein Profil. Dann muss er sein Passwort
ändern können. Dann braucht er Zahlungsmethoden. Dann Lieferadressen. Ehe du
dich versiehst, ist deine User.php ein 2.000-Zeilen-Monstrum, das jedes
bekannte Design-Prinzip verletzt.

Das ist das “Gott-Aggregat”-Problem, und hier kommt Domain-Driven Design (DDD)
zur Rettung. Genauer gesagt, zwei Schlüsselkonzepte: den wahren Job des
Aggregat-Roots zu verstehen und zu lernen, wie man große Aggregate
aufteilt.

In diesem Post werden wir praktisch und zeigen, wie man diese Ideen mit
patchlevel/eventsourcing umsetzt, einer modernen PHP-Bibliothek, die das Ganze
überraschend elegant macht.

Teil 1: Der wahre Job des Aggregat-Roots (Er ist ein Türsteher)

Stell dir einen Aggregat-Root wie einen Türsteher in einem Nachtclub vor. Sein
einziger Job ist es, die Integrität des Clubs zu schützen (die Geschäftsregeln
oder “Invarianten”). Er lässt nicht einfach jeden rein, um an den Möbeln
herumzuspielen. Alle Anfragen müssen über den Türsteher laufen, der entscheidet,
ob sie gültig sind.

In patchlevel/eventsourcing übersetzt sich das in einen einfachen, aber
mächtigen Workflow:

Eine öffentliche Methode empfängt einen Command (eine Anfrage zur
Zustandsänderung).
Die Methode validiert diesen Command gegen den aktuellen Zustand des
Aggregats.
Wenn gültig, zeichnet sie ein Event auf. Sie ändert den Zustand nicht
direkt.
Eine separate, private #[Apply]-Methode ist dafür verantwortlich, den
Zustand basierend auf dem Event tatsächlich zu ändern.

Lass uns ein SupportTicket-Aggregat modellieren. Invariante: Ein Ticket
kann von einem Benutzer nur geschlossen werden, wenn es ihm zugewiesen ist.

// src/Support/Domain/Ticket.php
declare(strict_types=1);

namespace App\Support\Domain;

use Patchlevel\EventSourcing\Aggregate\BasicAggregateRoot;
use Patchlevel\EventSourcing\Attribute\Aggregate;
use Patchlevel\EventSourcing\Attribute\Apply;
use Patchlevel\EventSourcing\Attribute\Id;

#[Aggregate('ticket')]
final class Ticket extends BasicAggregateRoot
{
    #[Id]
    private TicketId $id;
    private ?UserId $assigneeId = null;
    private bool $isClosed = false;

    public static function raise(TicketId $id, string $summary): self
    {
        $self = new self();
        $self->recordThat(new TicketRaised($id, $summary));

        return $self;
    }

    public function assign(UserId $assigneeId): void
    {
        if ($this->isClosed) {
            throw new \DomainException('Ein geschlossenes Ticket kann nicht zugewiesen werden.');
        }
        $this->recordThat(new TicketAssigned($assigneeId));
    }

    public function close(UserId $userId): void
    {
        if ($this->isClosed) {
            return; // Idempotent: Bereits geschlossen, nichts zu tun.
        }

        // Das ist der Invarianten-Check!
        if ($this->assigneeId === null || !$this->assigneeId->equals($userId)) {
            throw new \DomainException('Ticket kann nur vom zugewiesenen Benutzer geschlossen werden.');
        }

        $this->recordThat(new TicketClosed());
    }

    #[Apply]
    private function applyTicketRaised(TicketRaised $event): void
    {
        $this->id = $event->ticketId;
        $this->isClosed = false;
    }

    #[Apply]
    private function applyTicketAssigned(TicketAssigned $event): void
    {
        $this->assigneeId = $event->assigneeId;
    }

    #[Apply]
    private function applyTicketClosed(TicketClosed $event): void
    {
        $this->isClosed = true;
    }
}

Die close()-Methode ist unser Türsteher. Sie prüft die Regel und, wenn alles
cool ist, macht sie ein recordThat() mit einem Event. Die Zustandsänderung
selbst ist sauber in der applyTicketClosed()-Methode versteckt. Diese Trennung
ist der Kern von Event Sourcing.

Teil 2: Das Gott-Aggregat killen

Unser User-Objekt ist immer noch ein Problem. Es kümmert sich um
Authentifizierung (Account) und persönliche Infos (Profile). Das sind zwei
verschiedene Business-Kontexte. Der Versuch, sie in einem Aggregat zu managen,
ist ein Rezept für eine Katastrophe. Was, wenn ein User sein Profilbild
aktualisieren will, während ein Passwort-Reset läuft? Du bekommst
Transaktionskonflikte auf demselben Objekt aus völlig unabhängigen Gründen.
Total nervig.

Die Lösung ist, das Gott-Aggregat aufzuteilen.

Vorher: Das `User` Gott-Aggregat

#[Aggregate('user')]
final class User extends BasicAggregateRoot
{
    // ...tonnenweise Properties für E-Mail, Passwort, Name, Bio, etc.

    public function changePassword(string $newPassword): void { /* ... */ }
    public function updateBio(string $newBio): void { /* ... */ }

    #[Apply]
    private function applyPasswordChanged(PasswordChanged $event): void { /* ... */ }

    #[Apply]
    private function applyBioUpdated(BioUpdated $event): void { /* ... */ }
}

Nachher: Aufteilung in `Account` und `Profile`

Wir erstellen zwei neue, kleinere Aggregate.

Das Account-Aggregat:

#[Aggregate('account')]
final class Account extends BasicAggregateRoot
{
    #[Id]
    private AccountId $id;
    private string $email;

    public function changePassword(string $newPassword): void { /* ... */ }

    #[Apply]
    private function applyPasswordChanged(PasswordChanged $event): void { /* ... */ }
}

Das Profile-Aggregat:

#[Aggregate('profile')]
final class Profile extends BasicAggregateRoot
{
    #[Id]
    private ProfileId $id; // Kann dieselbe sein wie die AccountId
    private string $bio;

    public function updateBio(string $newBio): void { /* ... */ }

    #[Apply]
    private function applyBioUpdated(BioUpdated $event): void { /* ... */ }
}

Viel sauberer. Wie hängen sie jetzt zusammen? Wir benutzen Domain Events. Wenn
ein neuer Account erstellt wird, könnte er ein AccountCreated-Event
auslösen. Ein Listener kann das aufschnappen und einen Command auslösen, um ein
zugehöriges Profile zu erstellen. Sie sind über eine ID verbunden, aber
transaktional unabhängig.

Ein pragmatischer Ansatz: Micro-Aggregates

Event-Streams zu migrieren kann komplex sein. patchlevel/eventsourcing bietet
einen genialen Zwischenschritt mit dem #[Stream]-Attribut. Du kannst mehrere
Aggregate denselben Stream teilen lassen.

#[Aggregate('profile')]
#[Stream(Account::class)] // Lauscht auf den Account-Stream
final class Profile extends BasicAggregateRoot
{
    #[Id]
    private AccountId $id; // Wir benutzen die AccountId
    private string $bio;

    // ...

    #[Apply]
    private function applyAccountCreated(AccountCreated $event): void
    {
        // Wenn ein Account erstellt wird, erstellen wir den Profile-Zustand
        $this->id = $event->accountId;
        $this->bio = 'Neues Benutzerprofil';
    }

    #[Apply]
    private function applyBioUpdated(BioUpdated $event): void { /* ... */ }
}

Hier ist das Profile ein “Micro-Aggregat”, das sich auf den Event-Stream des
Account draufsetzt. Das ist eine fantastische Methode, um mit dem Refactoring
zu beginnen, ohne ein riesiges Datenmigrationsprojekt starten zu müssen.

Deine Logik testen (ohne Datenbank)

Das Schöne an diesem Pattern ist die Testbarkeit. patchlevel/eventsourcing
liefert ein AggregateRootTestCase.

final class TicketTest extends AggregateRootTestCase
{
    protected function aggregateClass(): string
    {
        return Ticket::class;
    }

    public function testCloseTicketFailsIfNotAssigned(): void
    {
        $this->expectException(\DomainException::class);

        $ticketId = TicketId::fromString('123');
        $userId = UserId::fromString('456');

        $this
            ->given(new TicketRaised($ticketId, 'Mein Bildschirm ist kaputt'))
            ->when(fn(Ticket $ticket) => $ticket->close($userId))
            ->then(/* Keine Events sollten aufgezeichnet werden */);
    }
}

Wir können unsere Kern-Business-Logik komplett isoliert testen. Schnell, einfach
und zuverlässig.

Fazit

Indem du diese beiden DDD-Prinzipien beherzigst – lass deinen Aggregat-Root ein
strenger Türsteher sein und teile Gott-Objekte rücksichtslos auf – kannst du
eine chaotische Codebase in eine Sammlung sauberer, wartbarer und testbarer
Domain-Modelle verwandeln.

Event Sourcing mit einer Bibliothek wie patchlevel/eventsourcing macht dieses
Muster natürlicher als je zuvor. Du hörst auf, in “Zeilen in einer Tabelle
updaten” zu denken und fängst an, in “Business-Fakten aufzeichnen” zu denken. Es
ist ein kleiner Shift im Kopf, aber er macht den ganzen Unterschied.

Was ist das schlimmste Gott-Objekt, das dir je untergekommen ist? Teile deine
Horrorgeschichten auf Twitter oder LinkedIn.

Weiterführende Literatur:

DDD mit Event Sourcing: So baust du Aggregate, die nicht explodieren #

Einleitung: Das unvermeidliche Gott-Objekt #

Teil 1: Der wahre Job des Aggregat-Roots (Er ist ein Türsteher) #

Teil 2: Das Gott-Aggregat killen #

Vorher: Das User Gott-Aggregat #

Nachher: Aufteilung in Account und Profile #

Ein pragmatischer Ansatz: Micro-Aggregates #

Deine Logik testen (ohne Datenbank) #

Fazit #