© SharonPhoto/shutterstock.com
Kiosk Specials
Teil 2: Zustandsverwaltung mit NgRx und Fassaden

Domain-Layer für den Projektstart

Fassaden bereiten die Möglichkeiten einer Domäne für einzelne Anwendungsfälle auf und verbergen Details der Zustandsverwaltung.

Manfred Steyer


Jeder Entwickler und jede Entwicklerin dürfte dieses Problem kennen: Nach einer Änderung an einer Stelle funktioniert plötzlich eine ganz andere nicht mehr. Der Grund für dieses „Kaputt erweitern“ ist häufig eine zu starke Verknüpfung der einzelnen Systembestandteile. Wer wartbare Softwaresysteme möchte, muss also Entkopplung anstreben.

Domain-driven Design, genauer gesagt, dessen Disziplin Strategic Design, bietet hierfür eine Lösung: Es unterteilt Anwendungen in (Sub-)Domänen, die so wenig wie möglich voneinander wissen müssen.

Zur Organisation der einzelnen Domänen bieten sich hexagonale Architekturen oder auch Layer an. Der erste Artikel dieser dreiteiligen Serie hat für das Frontend unter anderem zwei Arten von fachlichen Layern vorgeschlagen: Der Featurelayer beinhaltet fachliche UI-Komponenten, die den Benutzer durch einen Anwendungsfall leiten. Der Domain-Layer hingegen enthält die Domänenlogik.

Den Domain-Layer wollen wir in diesem Artikel anhand einer Angular-basierten Fallstudie etwas näher betrachten. Den Quellcode gibt es wie immer in meinem GitHub-Account [1].

ArtikelserieTeil 1: Domänenschnitt mit Nx MonoreposTeil 2: Zustandsverwaltung mit NgRx und FassadenTeil 3: OAuth 2.0 und die neuen Security Best Practices

Domänenlogik

Es lässt sich vortrefflich darüber streiten, ob ein Frontend überhaupt Domänenlogik beinhaltet. Schließlich hat es sich ja bewährt, diese im Backend zu kapseln. Auf der anderen Seite sind moderne SPAs aber auch mehr als bloße Empfänger von Datentransferobjekten. Gerade wenn State-Management-Lösungen im Spiel sind, sammeln sich nach und nach umfangreiche Modelle an, die nicht selten anwendungsfallübergreifend zum Einsatz kommen.

Diese Modelle unterliegen bestimmten Regeln, und manche darauf basierende Berechnungen gilt es zur Verbesserung der Benutzerfreundlichkeit auch schon vorab im Frontend zu erledigen. Genau um diese Aspekte geht es hier.

Um zu verhindern, dass sich Domänenlogik mit anderen Aspekten wie Anwendungsfällen oder Datenzugriff vermengt, hat es sich eingebürgert, sie zu isolieren (Abb. 1).

Abb. 1: Domänenbibliothek

Während die eigentliche Domänenschicht in der Mitte die angesprochenen Modelle und die darauf anzuwendenden Logiken enthält, bietet der Application-Layer anwendungsfallspezifische Fassaden an. Diese Fassaden, die auch Details des Zustandsmanagements verbergen, korrelieren nicht nur mit den Application Services in DDD, sondern sind auch unabhängig davon in der letzten Zeit im Angular-Umfeld sehr beliebt...

Kiosk Specials
Teil 2: Zustandsverwaltung mit NgRx und Fassaden

Domain-Layer für den Projektstart

Fassaden bereiten die Möglichkeiten einer Domäne für einzelne Anwendungsfälle auf und verbergen Details der Zustandsverwaltung.

Manfred Steyer


Jeder Entwickler und jede Entwicklerin dürfte dieses Problem kennen: Nach einer Änderung an einer Stelle funktioniert plötzlich eine ganz andere nicht mehr. Der Grund für dieses „Kaputt erweitern“ ist häufig eine zu starke Verknüpfung der einzelnen Systembestandteile. Wer wartbare Softwaresysteme möchte, muss also Entkopplung anstreben.

Domain-driven Design, genauer gesagt, dessen Disziplin Strategic Design, bietet hierfür eine Lösung: Es unterteilt Anwendungen in (Sub-)Domänen, die so wenig wie möglich voneinander wissen müssen.

Zur Organisation der einzelnen Domänen bieten sich hexagonale Architekturen oder auch Layer an. Der erste Artikel dieser dreiteiligen Serie hat für das Frontend unter anderem zwei Arten von fachlichen Layern vorgeschlagen: Der Featurelayer beinhaltet fachliche UI-Komponenten, die den Benutzer durch einen Anwendungsfall leiten. Der Domain-Layer hingegen enthält die Domänenlogik.

Den Domain-Layer wollen wir in diesem Artikel anhand einer Angular-basierten Fallstudie etwas näher betrachten. Den Quellcode gibt es wie immer in meinem GitHub-Account [1].

ArtikelserieTeil 1: Domänenschnitt mit Nx MonoreposTeil 2: Zustandsverwaltung mit NgRx und FassadenTeil 3: OAuth 2.0 und die neuen Security Best Practices

Domänenlogik

Es lässt sich vortrefflich darüber streiten, ob ein Frontend überhaupt Domänenlogik beinhaltet. Schließlich hat es sich ja bewährt, diese im Backend zu kapseln. Auf der anderen Seite sind moderne SPAs aber auch mehr als bloße Empfänger von Datentransferobjekten. Gerade wenn State-Management-Lösungen im Spiel sind, sammeln sich nach und nach umfangreiche Modelle an, die nicht selten anwendungsfallübergreifend zum Einsatz kommen.

Diese Modelle unterliegen bestimmten Regeln, und manche darauf basierende Berechnungen gilt es zur Verbesserung der Benutzerfreundlichkeit auch schon vorab im Frontend zu erledigen. Genau um diese Aspekte geht es hier.

Um zu verhindern, dass sich Domänenlogik mit anderen Aspekten wie Anwendungsfällen oder Datenzugriff vermengt, hat es sich eingebürgert, sie zu isolieren (Abb. 1).

Abb. 1: Domänenbibliothek

Während die eigentliche Domänenschicht in der Mitte die angesprochenen Modelle und die darauf anzuwendenden Logiken enthält, bietet der Application-Layer anwendungsfallspezifische Fassaden an. Diese Fassaden, die auch Details des Zustandsmanagements verbergen, korrelieren nicht nur mit den Application Services in DDD, sondern sind auch unabhängig davon in der letzten Zeit im Angular-Umfeld sehr beliebt...

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