Architekturarbeit in der IT ist seit vielen Jahren ein schwieriges und häufig missverstandenes Thema. Dazu kommt, dass die Effekte der Hyperspezialisierung und Technologieexplosion dazu führen, dass IT-Architekturen die eigentliche Problemstellung oft immer schlechter unterstützen. Man findet immer häufiger One-Size-fits-all-Lösungen oder rein hypegetriebene Architekturen. Trotzdem deutet nichts auf eine Umkehr dieses Negativtrends hin. Zeit für eine Bestandsaufnahme und einen Blick auf die daraus resultierenden Probleme für die Architekturarbeit.

Die Architektur definiert die Struktur eines Softwaresystems und ist zentral für den Erfolg eines Projekts. Deswegen ist Softwarearchitektur so wichtig. Aber in Wirklichkeit ist Softwarearchitektur noch viel mehr, und eine erfolgreiche Softwarearchitektur erfordert viele, teilweise überraschende Maßnahmen.

Domain-driven Design (DDD) ist eine alte Technik, aber gerade voll im Trend. Worum geht es bei DDD und ist der Hype berechtigt?

Architekturarbeit in der IT ist seit vielen Jahren ein schwieriges und häufig missverstandenes Thema. Dazu kommt, dass die Effekte der Hyperspezialisierung und Technologieexplosion dazu führen, dass IT-Architekturen die eigentliche Problemstellung oft immer schlechter unterstützen. Man findet immer häufiger One-Size-fits-all-Lösungen oder rein hypegetriebene Architekturen. Trotzdem deutet nichts auf eine Umkehr dieses Negativtrends hin. Zeit für eine Bestandsaufnahme und einen Blick auf die daraus resultierenden Probleme für die Architekturarbeit.

Nur wenn wir die Landschaft um uns herum kennen, können wir unsere Route durch unwegsames Gelände sinnvoll planen. Landkarten (Maps) helfen uns dabei, Hindernisse gezielt zu umgehen, auf dem Weg befindliche Chancen zu erkennen und günstige Ausgangspositionen für kommende Etappen zu finden. Zeichnen wir also eine Karte!

Der Entwurf von nachhaltigen Softwarearchitekturen ist eine Herausforderung: Mit der Größe steigt in vielen klassisch objektorientierten Softwareprojekten die Komplexität überproportional an. Durch viel Disziplin und regelmäßige Refaktorisierungen lässt sich das Problem eine Weile in Schach halten, aber die wechselseitigen Abhängigkeiten und komplexen Abläufe von Zustandsveränderungen nehmen mit der Zeit trotzdem zu. Die funktionale Softwarearchitektur geht an die Strukturierung großer Systeme anders heran als objektorientierte Ansätze und vermeidet so viele Quellen von Komplexität und Wechselwirkungen im System.

In jedem Unternehmen gibt es große Softwaresysteme, die über viele Jahre weiterentwickelt wurden und deren Wartung Jahr für Jahr immer zäher und teurer wird. Vor dem Hintergrund neuer Architekturparadigmen wie Microservices sollen diese Systeme nun modern, skalierbar und flexibel werden. Dabei ist die Hoffnung, dass man sich der großen, schwerfälligen Monolithen entledigen kann, indem man sie in kleinere, besser zu beherrschende Microservices zerlegt.

Im Folgenden wollen wir ein mit Azure Functions – also serverless – implementiertes API mit modernen Mitteln absichern, indem wir eine JSON-Web-Token-(JWT-)Validierung hinzufügen. Vorkenntnisse in OAuth 2 [1], JWT [2] und Identity Provider (IDP) [3] sind von Vorteil, aber nicht zwingend notwendig.

Weder Domain-driven Design (DDD) noch Microservices sind konzeptionell neu. Trotzdem erfahren beide Themen seit einigen Jahren zunehmend mehr Zuspruch und werden immer häufiger auch gemeinsam genannt. Woran liegt das?

Mit Angular können wir viel kleinere Bundles an den Webbrowser übergeben. Auch das Rebuilding wird schneller. Wie hat das Angular-Team das bewerkstelligt?

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?

In Teil 2 dieser Serie [1] haben uns Carola Lilienthal und Michael Plöd gezeigt, wie man eine Domäne in mehrere Bounded Contexts aufteilt. Dabei erhalten wir statt einem großen, schwer verständlichen und schwer wartbaren Domänenmodell nun mehrere, besser handhabbare Domänenmodelle. In diesem Teil der Serie schauen wir darauf, wie man das einzelne Domänenmodell konkret implementieren kann.