© Liashko/Shutterstock.com
Nachhaltige Angular-Architekturen mit Strategic und Tactical Design

DDD im Frontend


Strategic Design bietet eine etablierte Methodik zum Schneiden großer Anwendungen in möglichst autarke Domänen. Nx erlaubt die Umsetzung dieser Domänen in einem Angular Monorepo und stellt sicher, dass dabei möglichst wenig Abhängigkeiten entstehen. Ausgewählte Ideen von Tactical Design unterstützen dabei.

Angular bietet sich aufgrund seiner Struktur und des gebotenen Leistungsumfangs für die Umsetzung großer Frontends an. Um solche Systeme beherrschbar zu gestalten, gilt es, sie in kleine und wenig komplexe Module zu untergliedern. Das ist soweit bekannt. Die Frage, die sich hierbei jedoch immer wieder aufdrängt, ist, nach welchen Kriterien der Modulschnitt erfolgen soll. Außerdem gilt es, festzulegen, wie diese Module zu implementieren sind, aber auch, wie sie untereinander kommunizieren können.

Dieser Artikel gibt zunächst eine Antwort basierend auf den Ideen des Strategic Designs aus DDD. Danach zeigt der Artikel, wie sich eine solche Architektur mit Nx [1], einer populären und freien Erweiterung für die Angular CLI, umsetzen lässt. Außerdem besprechen wir ausgewählte Ideen aus Tactical Design, die bei der Umsetzung helfen. Die verwendeten Beispiele finden sich wie immer in meinem GitHub-Account [2].

Vertikale und horizontale Trennlinien

Domain Driven Design sieht vor, dass ein Gesamtsystem in mehrere kleine, möglichst autarke Subdomänen zu untergliedern ist. Dieses Vorgehen nennt sich auch Strategic Design.

Sind diese Subdomänen erst einmal identifiziert, stellt sich die Frage, wie sie strukturiert werden sollen. Eine klassische Vorgehensweise sieht die Unterteilung in Schichten vor. Diesen Ansatz verfolgt auch der vorliegende Text (Abb. 1).

steyer_ddd_1.tif_fmt1.jpgAbb. 1: Domänen und Layer

Alternativ zur Schichtentrennung lassen sich auch eine hexagonale Architektur oder Ideen aus Clean Architecture einsetzen. Dank des in Angular integrierten Dependency-Injection-Mechanismus gestalten sich auch solche Implementierungen sehr gradlinig.

Wie Abbildung 1 zeigt, führt die verfolgte Vorgehensweise zu einer vertikalen Unterteilung nach Subdomänen und zu einer zusätzlichen horizontalen Unterteilung nach Schichten. Für jene Aspekte, die domänenübergreifend zu nutzen sind, kommt ein zusätzlicher vertikaler Abschnitt mit der Bezeichnung „shared“ zum Einsatz. Seine fachlichen Teile entsprechen dem von DDD vorgeschlagenen Shared Kernel. Zusätzlich beherbergt er technische Bibliotheken, z. B. für Authentifizierung und Logging.

Jede Schicht erhält nun eine oder mehrere Bibliotheken. Zu...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang