Diese Modularitätsformen führen bei wachsender Komplexität der Anwendung immer mehr in ein Dependency-Wirrwarr, das immer schwerer zu durchschauen wird und es immer schwieriger und aufwändiger macht, neu entstehende Abhängigkeitsprobleme zwischen den Komponenten aufzulösen. Diese Situation wird häufig Dependency-Hölle genannt. Im letzten Blog hatte ich zwei Modularitätsformen vorgestellt (ebenfalls mit jeweils einer Implementierung der HOO-Fachdomäne), bei denen keine Dependency-Hölle entstehen kann, weil wechselseitige und zyklische Abhängigkeiten problemlos möglich sind (Microservices und das fachlich offene Dependency Management).
Der Unterschied zwischen diesen beiden Gruppen von Modularitätsformen ist bedeutend, denn für die letztgenannte Gruppe ist eine völlig andere Art der Programmsteuerung möglich. Die zur ersten Gruppe gehörenden Implementierungen folgen dem Prinzip der Orchestrierung. Dabei spielte das Control-Modul die Rolle des Dirigenten und die übrigen Komponenten stellten das Orchester dar. Das Control-Modul beinhaltete den wesentlichen Teil der Business-Logik und kommunizierte mit den übrigen Modulen, die untereinander keine Informationen austauschen. Eine völlig andere Art der Programmsteuerung stellt die Choreographie dar. Hier gibt es keinen Dirigenten, der den Ablauf des Programms explizit beschreibt. Stattdessen kommunizieren die einzelnen Komponenten in einer Art von Peer-To-Peer-System miteinander, so wie in einer SOA beliebige WebServices miteinander kommunizieren. Die Programmsteuerung ergibt sich dabei nur implizit durch den wechselseitigen Aufruf der Komponenten.
Dieser Blog stellt zwei weitere HOO-Implementierungen vor, die dem Prinzip der Choreographie folgen. Und zwar für die beiden Modularitätsformen Microservices und fachlich offenes Dependency Management, da hier wechselseitige und zyklische Abhängigkeiten möglich sind.
Der Unterschied zwischen Orchestrierung und Choreographie wird deutlich, wenn wir uns einen Ausschnitt aus den UML-Sequenz-Diagrammen für beide Formen der Programmsteuerung am Beispiel der HOO-Fachdomäne anschauen:
In den Implementierungen, die der Choreographie folgen, gibt es eine zyklische Abhängigkeit zwischen Order, Horoscope und Invoice, während das mit der Orchestrierung nicht der Fall ist, weil alle Kommunikation nur bidirektional vom „Dirigenten“ zu den einzelnen Komponenten erfolgt. Letzteres hat den kleinen Nachteil eine Komponente mehr verwalten zu müssen, diese ist aber in der Regel ihren Preis wert, denn sie macht die Geschäftslogik explizit. Das bedeutet, der Ausspruch „Der Code ist die beste Dokumentation“ (weil meistens die EinzigeJ) stimmt in diesem Fall tatsächlich. Im Falle der Choreographie hingegen, ist das, was beim Programmablauf passiert viel weniger transparent. Schon bei mäßiger Komplexität kann praktisch nur noch zur Laufzeit verfolgt werden, wie der Programmfluss durch das ganze System aussieht. Die Choreographie ist also nicht grundsätzlich zu empfehlen, aber wenn sie realisiert werden soll, ist eine Modularitätsform nötig, die wechselseitige und zyklische Abhängigkeiten erlaubt, also eine Microservice Architektur oder das fachlich offene Dependency Management.
Zusammen mit dem klassischen Monolithen aus Blog 3 dieser Blogserie habe ich jetzt 8 verschiedene Implementierungen der HOO-Fachdomäne vorgestellt. Im nächsten und letzten Blog möchte ich diese abschließend vergleichen.
