Entwurfsprinzipien für
Moderne Verteilte Anwendungen

Die unabhängige Testbarkeit ersetzt aber nicht die Notwendigkeit von Integrationstests.

Dynamische Kopplung entsteht zur Laufzeit durch den Austausch von Nachrichten, statische Kopplung zur Compilezeit.

(Temporale Kopplung bezieht sich darauf, dass etwas gleichzeitig ausgeführt wird.)

Hohe Kopplung ist aber nicht per-se schlecht! Eine hohe Kopplung an Dinge, die extrem stabil sind, ist im Allgemeinen unkritisch.

Keine Kopplung ist (auch) nicht wünschenswert, da dies zu Entitäten führt, die alle Arbeit durchführen; weiterhin führt dies auch dazu, dass sich ggf. die Arbeit sehr viel schlechter aufteilen lässt und dann eine agile Entwicklung mit einem kleinen Team nicht mehr möglich ist.

Relevante Frage: Wer ist/sollte der Eigentümer der Schnittstellen sein? D. h. aus welcher Perspektive sollte die Schnittstelle entworfen werden?

Eine wesentliche Frage ist: Worin besteht der abgeschlossene Kontext, um etwas auf einer entsprechenden Abstraktionsebene kohäsiv erscheinen zu lassen?

Technische Kohäsion entsteht zum Beispiel an der Schnittstelle für den Zugriff auf die Datenbank.

Services mit einer geringen Kohäsion repräsentieren häufig Dinge auf sehr grober, abstrakter Ebene und haben Verantwortlichkeiten übernommen für Dinge, die sie bessere delegieren sollten.

Bei der Verteilung der Zuständigkeiten gibt es eine große Bandbreite in Hinblick darauf, wie die nicht-funktionalen - und die funktionalen Eigenschaften einer Software realisiert werden.

Single Responsibility Principle (SRP):

Ein Modul sollte nur einem einzigen Akteur gegenüber verantwortlich sein. D. h. es sollte nur eine wohldefinierte Gruppe von Akteuren geben, die eine Veränderung veranlassen/verlangen können. Code, von dem verschiedene Akteure abhängen, sollte aufgeteilt werden.

Common Closure Principle (CCP):

Fasse in Komponenten solche Klassen zusammen, die sich aus dem gleichen Grund und zur gleichen Zeit ändern. z. B. weil sie die gleichen Stakeholder haben oder die gleichen rechtlichen Grundlagen haben.

Die beiden Prinzipien sind eng miteinander verwandt. Das CCP ist ein Prinzip, das auf allen Abstraktionsgeraden angewendet werden kann. Das SRP ist - zumindest ursprünglich - ein Prinzip, das nur auf der Ebene von Klassen und Modulen angewendet wurde.

Begründung

Gute Softwarekonzepte sind in Module gegliedert.

High-Level-Module enthalten die wichtigen politischen Entscheidungen und Geschäftsmodelle einer Anwendung. Sie definieren die Identität der Anwendung.

Low-Level-Module enthalten detaillierte Implementierungen einzelner Mechanismen, die zur Umsetzung der Richtlinie benötigt werden.

Darstellung einer Anwendung mit traditioneller Architektur.

Codeabhängigkeiten ergeben sich zum Beispiel beim Verwenden eines Object-relational Mappers (ORM).

Solch eine Architektur war Ende der 90er/Anfang der 2000er Standard und ist für einfache Programme auch heute noch akzeptabel, da diese häufig sehr schnell zu entwickeln sind und viel Erfahrung mit dieser Architektur vorhanden ist. Besser ist es jedoch gleich eine der folgenden Architekturen anzuwenden, um ggf. vorbereitet zu sein, wenn das System wächst.

Ziel der hexagonalen Architektur ist es die Anwendungslogik unabhängig von der UI und den Datenbanken etc. zu machen. Die Anwendungslogik/die Anwendungskomponenten sollen lose gekoppelt sein und einfach mit Ihrer Umgebung verbunden werden können durch die Nutzung von Ports & Adapters.

Für die Implementierung von Primary Ports werden oft Inversion of Control Frameworks verwendet. Die Implementierung von Secondary Ports erfordert üblicherweise den Einsatz von Dependency Inversion.

Im Allgemeinen ist es oft notwendig in den Adaptern Entity Klassen hin und zurück zu Mappen, um sicherzustellen, dass keine technischen Abhängigkeiten in den Kern einsickern.

Die hexagonale Architektur wird von einigen als Ausgangsarchitektur für Microservices gesehen, da häufig einzelne Services nach diesem Architekturmuster implementiert werden.

Meine Heransgehensweise für die Planung einer komplexen Geschäftsanwendung ist in der Regel eine Kombination aus Domain Driven Design, Microservices und hexagonaler Architektur: Einsatz von Strategic Design zur Planung von Core Domain, Sub Domains und Bounded Contexts. Aufteilung eines Bounded Contexts in einen oder mehrere Microservices. Ein Microservice kann ein oder mehrere Aggregates enthalten, aber auch den kompletten Bounded Context, sofern dieser nicht zu groß ist (und statt des gewünschten Microservices wieder ein Monolith entsteht).

—https://www.happycoders.eu/de/software-craftsmanship/hexagonale-architektur/

Schlüssellehren der Onion Architecture (Zwiebelarchitektur):

• Die Anwendung ist rund um ein unabhängiges Objektmodel gebaut.

• Innere Schichten definieren Schnittstellen.

• Äußere Schichten implementieren Schnittstellen.

• Die Richtung der Kopplung ist immer in Richtung zum Zentrum!

• Der Anwendungskern (Application Core) kann immer ohne die Infrastruktur kompiliert und davon unabhängig ausgeführt werden.

Entities

Entities (Entitäten) kapseln unternehmensweite kritische Geschäftsregeln.

• Objekte mit Methoden

• Datastrukturen

• Funktionen

• ...

Entitäten sind Dinge, die sich nicht aufgrund externer (technischer) Änderungen ändern sollten. Zum Beispiel aufgrund von geänderten Sicherheitsanforderungen oder der verwendeten Datenbank.

Use Cases

Anwendungsspezifische Geschäftsregeln orchestrieren den Fluss der Daten von und zu den Entitäten; Änderungen an den Anwendungsfällen (Use Cases) sollten auf die Entitäten keinen Einfluss haben.

Controllers, Gateways, Presenters

Die Aufgabe des Rings der Schnittstellen und Adapter ist die Konvertierung der Daten der Anwendungsfällen/Use Cases bzw. Entitäten und dem Format, dass für die externen Funktionalitäten sinnvoll ist.

In diesem Ring erfolgt zum Beispiel die Implementierung des MVC Patterns für eine GUI, oder das ORM Mapping.

DBs, Web, Devices

In diesem Ring befinden sich die externen Details, in der Regel gibt es hier keinen oder nur minimalen Glue Code.

Code Abhängigkeiten

Wie bei den anderen Architekturen auch, gehen auch hier die Abhängigkeiten immer von außen nach innen. D. h. die Entitäten sind von nichts abhängig, die Anwendungsfälle von den Entitäten, die Schnittstellen von den Anwendungsfällen und die externen Details von den Schnittstellen.

Mit einer solchen Implementierung sind auch echte initiale Kosten verbunden - mehrere Interfaces müssen implementiert und gewartet werden. Partielle Lösungen sind denkbar, müssen aber wohl überlegt sein, um ungewünschte Abhängigkeiten zu vermeiden, die häufig zu einer schlechten Wartbarkeit und langfristigen bzw. verzögerten Kosten führen.