Seminar NestJS – Architektur mit DDD, CQRS und Event Sourcing

Mit wachsender Fachlichkeit reicht eine technisch saubere Modulstruktur nicht aus. Geschäftsregeln, Zuständigkeiten und Integrationsgrenzen müssen so modelliert werden, dass Änderungen lokal bleiben und fachliche Begriffe im Code eindeutig sind.

Der Kurs entwickelt aus einer zunächst gekoppelten Anwendung eine klar geschnittene Architektur. Domain-driven Design liefert den fachlichen Rahmen, CQRS trennt Änderungs- und Lesemodelle, und Event Sourcing wird nur dort eingesetzt, wo Historie und Rekonstruktion einen messbaren Nutzen besitzen.

Inhaltsübersicht

• Lernziele
• Domänenschnitt und gemeinsame Sprache
• Taktisches Design in NestJS
• CQRS mit Commands, Queries und Events
• Event Sourcing und Projektionen
• Konsistenz, Integration und Architekturtests
• Praxisprojekt: Auftragsdomäne mit Ereignishistorie
• Prüfpunkte und typische Fehler

Lernziele

• Fachdomänen, Subdomänen, Bounded Contexts und Integrationsbeziehungen belastbar schneiden.
• NestJS-Module entlang fachlicher Verantwortlichkeiten statt technischer Schichten strukturieren.
• Aggregates, Value Objects, Domain Services und Repositories mit klaren Invarianten modellieren.
• Commands, Queries und Events mit dem CQRS-Modul konsistent einsetzen.
• Event-Sourcing-Entscheidungen, Event-Schemata, Projektionen und Versionsstrategien bewerten.
• Konsistenz, Idempotenz, Sagas und automatisierte Architekturtests absichern.

Domänenschnitt und gemeinsame Sprache

Die Architektur beginnt mit fachlichen Ereignissen, Entscheidungen und Verantwortlichkeiten. Technische Begriffe werden zurückgestellt, bis Grenzen und Bedeutung zentraler Begriffe geklärt sind.

1. Akteure, Geschäftsziele, Entscheidungen und relevante Ereignisse erfassen.
2. Begriffe mit mehreren Bedeutungen identifizieren und kontextabhängig präzisieren.
3. Zusammengehörige Regeln und Daten zu Kandidaten für Bounded Contexts gruppieren.
4. Upstream- und Downstream-Beziehungen sowie notwendige Übersetzungen dokumentieren.
5. Schnittstellen nach fachlichen Verträgen statt nach Datenbanktabellen definieren.
6. Kontextgrenzen in eine modulare NestJS-Struktur überführen.

Entscheidungskriterien und Hinweise

• Bounded Contexts beschreiben Bedeutungsgrenzen und nicht automatisch Deploymentgrenzen.
• Ein gemeinsamer Begriff darf in verschiedenen Kontexten unterschiedliche Modelle besitzen.

Taktisches Design in NestJS

Das Domänenmodell bleibt unabhängig von Transport, Persistenz und Framework-Details. NestJS übernimmt Komposition und Adapter, während fachliche Regeln in testbaren Objekten liegen.

1. Aggregate-Grenzen nach konsistenten Geschäftsregeln und nicht nach Objektgraphen wählen.
2. Zustandsänderungen ausschließlich über fachlich benannte Methoden zulassen.
3. Value Objects unveränderlich gestalten und Validierung in deren Konstruktion bündeln.
4. Domain Services nur für Regeln einsetzen, die keinem einzelnen Aggregate gehören.
5. Repository-Verträge an Aggregate und fachliche Suchbedürfnisse ausrichten.
6. Ports und Adapter verwenden, um technische Abhängigkeiten aus dem Domänenkern fernzuhalten.

Entscheidungskriterien und Hinweise

• Persistenzmodelle werden nicht ungeprüft als Domänenobjekte verwendet.
• Aggregate bleiben so klein wie möglich und so groß wie für Invarianten erforderlich.

CQRS mit Commands, Queries und Events

CQRS wird schrittweise eingeführt. Zuerst werden Schreibabsichten und Leseabfragen semantisch getrennt; getrennte Modelle oder Speicher folgen nur bei nachgewiesenem Bedarf.

1. Anwendungsfälle als Commands mit eindeutiger Absicht und idempotenter Identität formulieren.
2. Command Handler als Orchestrierung zwischen Domäne, Repository und Transaktion aufbauen.
3. Queries auf konkrete Lesebedürfnisse zuschneiden.
4. Domain Events nach erfolgreicher Zustandsänderung kontrolliert veröffentlichen.
5. Event Handler nach fachlicher Relevanz und Fehlerauswirkung klassifizieren.
6. Sagas für länger laufende Abläufe mit Kompensation und Abbruchbedingungen modellieren.
7. Korrelation, Kausalität und Idempotenz über alle Nachrichten dokumentieren.

Entscheidungskriterien und Hinweise

• CQRS verlangt nicht zwingend getrennte Datenbanken oder Microservices.
• Domain Events beschreiben abgeschlossene fachliche Tatsachen.

Event Sourcing und Projektionen

Event Sourcing wird als bewusste Architekturentscheidung behandelt. Auditierbarkeit, zeitliche Rekonstruktion, Komplexität und Betriebsaufwand werden gegeneinander abgewogen.

1. Unveränderliche Events mit fachlicher Bedeutung, stabiler Identität und Metadaten entwerfen.
2. Optimistische Konkurrenzkontrolle über Stream-Versionen implementieren.
3. Aggregate aus Events rekonstruieren und Snapshots nur bei gemessenem Bedarf einsetzen.
4. Projektionen idempotent und vollständig neu aufbaubar gestalten.
5. Event-Schemaänderungen durch Upcasting, parallele Versionen oder Migrationsläufe behandeln.
6. Fehlgeschlagene Projektionen, Poison Events und Wiederanlauf operational einplanen.
7. Datenschutzanforderungen und Unveränderlichkeit frühzeitig abwägen.

Entscheidungskriterien und Hinweise

• Projektionen sind abgeleitete Daten und müssen reproduzierbar sein.
• Event Sourcing wird nicht als universelle Persistenzvorgabe verwendet.

Konsistenz, Integration und Architekturtests

An Kontextgrenzen werden zeitliche Verzögerung, Wiederholung und Ausfall als normale Systemzustände behandelt. Architekturtests sichern die beabsichtigten Abhängigkeitsrichtungen.

1. Outbox- und Inbox-Muster für atomare Zustandsänderung und verlässliche Veröffentlichung einsetzen.
2. Idempotente Handler und deduplizierbare Nachrichtenidentitäten definieren.
3. Eventually Consistent Read Models mit sichtbaren Zuständen und Wiederholungsstrategien gestalten.
4. Anti-Corruption Layer für fremde Modelle und externe Begriffe verwenden.
5. Importregeln zwischen Domain, Application und Infrastructure automatisiert prüfen.
6. Contract- und Szenariotests über Kontextgrenzen ergänzen.

Entscheidungskriterien und Hinweise

• Technische Wiederholung darf keine doppelte fachliche Wirkung erzeugen.
• Architekturregeln werden im Build geprüft und nicht nur dokumentiert.

Praxisprojekt: Auftragsdomäne mit Ereignishistorie

Eine monolithische Auftragsanwendung wird in fachliche Kontexte für Auftrag, Bestand und Abrechnung zerlegt. Der Auftragskontext verwendet Commands und Domain Events; ein separates Lesemodell stellt Status und Verlauf bereit.

Für einen ausgewählten Ablauf wird Event Sourcing eingesetzt. Projektionen, konkurrierende Änderungen, Wiederholungen und ein fehlerhafter Event Handler werden gezielt simuliert.

1. Domänenereignisse und Begriffe erfassen und daraus drei Bounded Contexts ableiten.
2. NestJS-Module, Ports und Adapter entlang der Kontextgrenzen anlegen.
3. Auftrags-Aggregate mit Value Objects und Invarianten implementieren.
4. Commands, Queries und Domain Events über den CQRS-Bus verbinden.
5. Event Stream mit Versionsprüfung speichern und Aggregate rekonstruieren.
6. Status- und Verlaufsprojektion aufbauen und einen vollständigen Rebuild durchführen.
7. Outbox, Idempotenz und Saga für die Bestandsreservierung ergänzen.
8. Architektur-, Unit-, Integrations- und Szenariotests ausführen.

Prüfpunkte und typische Fehler

• Bounded Contexts werden nicht mit technischen Deploymenteinheiten gleichgesetzt.
• Aggregate kontrollieren Invarianten, ohne unnötig große Transaktionen zu erzeugen.
• CQRS wird nur bis zu der für das Problem erforderlichen Stufe ausgebaut.
• Domain Events sind fachlich verständlich und versionsfähig.
• Projektionen sind deterministisch neu aufbaubar und behandeln Duplikate sicher.
• Event Sourcing wird nur dort eingesetzt, wo der Nutzen den zusätzlichen Betriebsaufwand rechtfertigt.