Bis hierher haben Sie den Workspace gebaut und Grenzen durchgesetzt. Offen blieb die Frage, wo die Grenzen verlaufen sollen. Eine Regel, die ein falsch geschnittenes Fachgebiet schützt, macht den Fehler nur teurer. Diese Lektion klärt, wie man Schnitte findet: mit der strategischen Seite von Domain-Driven Design (DDD). Das Ergebnis ist eine Kontextkarte der Kladde als Datei im Repository und eine Entscheidung dazu. Das Handwerk dahinter (Domänenmodell, Ereignisse, Event Storming) lehrt K4 in Modul 4.2; die Lektion verlinkt es und wiederholt es nicht.

Stand der Prüfung. Gelesen am Schreibtag, im Text der Seiten: Microsoft Learn „Use Domain Analysis to Model Microservices“ und die Einstiegsseite „Tackling Business Complexity in a Microservice with DDD and CQRS Patterns“ (sie ist kurz und verweist auf Bücher), außerdem der Beitrag „All about DDD for Angular & Frontend Architectures“ von angulararchitects.io. Ausgeführt (Node 24.22.3, TypeScript 6.0.3): das kleine Beispiel kontexte.ts unten, mit node kontexte.ts (Exit 0, Ausgabe unten) und tsc --noEmit --strict (Exit 0). Die Kontextkarte als Mermaid-Diagramm wurde nicht gerendert, die Dateien docs/kontexte.md und die ADR sind Text und nicht ausgeführt. Die Kontexte der Kladde folgen dem Plan dieses Kurses (Kontakte, Termine mit der Buchung, Ausschreibungen). K4 schneidet sechs Kontexte (zusätzlich Vertrieb, Angebote, Mandanten); wo K4 anders benennt, gilt K4 4.2.4 für die Namen der API-Seite, prüfen Sie dort.

Warum nach Fachlichkeit

Ein Angular-Projekt wächst gern in Ordnern wie components, services und models. Das fühlt sich ordentlich an und schneidet quer durch alles, was ein Mensch im Büro tut: Wer „Termine“ ändern soll, ändert in drei Ordnern, und jede Änderung berührt die der anderen. Der Beitrag von angulararchitects.io (im Text gelesen) fordert, ein großes Front End in kleinere Teile zu zerlegen, und zwar entlang der Geschäftsfunktionen statt der technischen Schichten; DDD, vor allem sein strategischer Teil, helfe dabei, solche Schnitte zu finden und zu prüfen. Die Learn-Seite sagt dasselbe für Dienste: nach Fähigkeiten des Geschäfts entwerfen, nicht nach waagerechten Schichten wie Datenzugriff, mit loser Kopplung und hoher Geschlossenheit.

Was Sie davon haben, ist handfest: Eine Änderung betrifft meist einen Schnitt, ein Team kann ihn besitzen, und der Lint-Lauf aus 0102 kann die Grenze durchsetzen.