© Excellent backgrounds/Shutterstock.com
Java Magazin
Nachhaltige Angular-Anwendungen mit taktischem DDD und Monorepos

Domain-driven Design in Angular?

Taktisches DDD hilft bei der Beherrschung der steigenden Komplexität in Single Page Applications (SPAs) und harmoniert noch dazu gut mit den in der Angular-Welt anzutreffenden Gepflogenheiten. Wie lassen sich bewährte Architekturkonzepte wie z. B. DDD nun in Verbindung mit modernen JavaScript-Businessanwendungen nutzen?

Manfred Steyer


Geschäfts- und Industrieanwendungen sind in der Regel langlebig. Eine Lebenszeitspanne von einer oder mehreren Dekaden ist keine Seltenheit. Dazu kommt, dass immer mehr Teile dieser Anwendungen zur Steigerung der Benutzerfreundlichkeit ins Frontend wandern und dort mittels JavaScript implementiert sind. Somit stellt sich die Frage, wie sich bewährte Architekturkonzepte in der Welt von JavaScript Frameworks einsetzen lassen.

Dieser Artikel liefert eine Antwort, die sich in der Praxis des Autors bereits mehrfach bewährt hat. Es geht dabei um die Nutzung von Domain-driven Design in Angular-Anwendungen sowie um die gemeinsame Nutzung von Best Practices aus beiden Welten. Da bereits in [1] über den Einsatz von Strategic Design in Angular-Anwendungen geschrieben wurde, fokussiert sich dieser Artikel auf die andere Seite der Medaille: Tactical Design. Die verwendeten Beispiele finden sich wie immer in meinem GitHub-Account unter [2].

Vertikale und horizontale Trennlinien

Domain-driven Design sieht vor, dass ein Gesamtsystem in mehrere kleine, möglichst autarke Subdomänen zu untergliedern ist. Jede Subdomäne ist separat zu modellieren und erhält ihre eigenen Entitäten, die den jeweiligen Geschäftsbereich bestmöglich widerspiegeln. Dieses Vorgehen nennt sich auch Strategic Design [1]. 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).

Abb. 1: Domänen und Layer

Alternativ zur Schichtentrennung lassen sich natürlich 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. Dessen fachliche Teile entsprechen dem von DDD vorgeschlagenen Shared Kernel. Zusätzlich beherbergt er technische Bibliotheken, z. B. für Authentifizierung oder Logging.

Jede Schicht erhält nun eine oder mehrere Bibliotheken. Zugriffsregeln zwischen diesen Bibliotheken führen zu einer losen Kopplung und somit zu einer gesteigerten Wartbarkeit. Typischerweise leg...

Java Magazin
Nachhaltige Angular-Anwendungen mit taktischem DDD und Monorepos

Domain-driven Design in Angular?

Taktisches DDD hilft bei der Beherrschung der steigenden Komplexität in Single Page Applications (SPAs) und harmoniert noch dazu gut mit den in der Angular-Welt anzutreffenden Gepflogenheiten. Wie lassen sich bewährte Architekturkonzepte wie z. B. DDD nun in Verbindung mit modernen JavaScript-Businessanwendungen nutzen?

Manfred Steyer


Geschäfts- und Industrieanwendungen sind in der Regel langlebig. Eine Lebenszeitspanne von einer oder mehreren Dekaden ist keine Seltenheit. Dazu kommt, dass immer mehr Teile dieser Anwendungen zur Steigerung der Benutzerfreundlichkeit ins Frontend wandern und dort mittels JavaScript implementiert sind. Somit stellt sich die Frage, wie sich bewährte Architekturkonzepte in der Welt von JavaScript Frameworks einsetzen lassen.

Dieser Artikel liefert eine Antwort, die sich in der Praxis des Autors bereits mehrfach bewährt hat. Es geht dabei um die Nutzung von Domain-driven Design in Angular-Anwendungen sowie um die gemeinsame Nutzung von Best Practices aus beiden Welten. Da bereits in [1] über den Einsatz von Strategic Design in Angular-Anwendungen geschrieben wurde, fokussiert sich dieser Artikel auf die andere Seite der Medaille: Tactical Design. Die verwendeten Beispiele finden sich wie immer in meinem GitHub-Account unter [2].

Vertikale und horizontale Trennlinien

Domain-driven Design sieht vor, dass ein Gesamtsystem in mehrere kleine, möglichst autarke Subdomänen zu untergliedern ist. Jede Subdomäne ist separat zu modellieren und erhält ihre eigenen Entitäten, die den jeweiligen Geschäftsbereich bestmöglich widerspiegeln. Dieses Vorgehen nennt sich auch Strategic Design [1]. 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).

Abb. 1: Domänen und Layer

Alternativ zur Schichtentrennung lassen sich natürlich 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. Dessen fachliche Teile entsprechen dem von DDD vorgeschlagenen Shared Kernel. Zusätzlich beherbergt er technische Bibliotheken, z. B. für Authentifizierung oder Logging.

Jede Schicht erhält nun eine oder mehrere Bibliotheken. Zugriffsregeln zwischen diesen Bibliotheken führen zu einer losen Kopplung und somit zu einer gesteigerten Wartbarkeit. Typischerweise leg...

Neugierig geworden?


   
Loading...

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