Softwarearchitekturmuster geben Hilfe bei der groben und grundsätzlichen Strukturierung von Code. Es sind geronnene Erkenntnisse zur Herstellung von Ordnung in Software, um sie länger wandelbar zu halten.

Über die Jahrzehnte hat es verschiedene Empfehlungen gegeben, wie solche Ordnung aussehen sollte. So wurden Generationen von Entwickelnden geleitet. Allerdings war diese Leitung nicht schmerzfrei; ich möchte sogar sagen, dass die Schmerzen zugenommen haben, seit zur Wandelbarkeit auch noch die Testbarkeit als Langlebigkeitsanforderung getreten ist. Einige Komplexität in Codebasen, die modernen Architekturmustern folgen, ist darauf zurückzuführen, eben diese Muster zu implementieren und die Testbarkeit zu erhöhen.

So entsteht oft ein Widerspruch in der Praxis: Die Befolgung eines Architekturmusters soll erleichtern - doch durch seine Befolgung entsteht zusätzlicher Aufwand. Ganz zu schweigen davon, dass grundlegende Übel wie überlange Funktionen dadurch gar nicht adressiert werden.

Als Wurzelproblem dahinter habe ich funktionale Abhängigkeiten identifiziert. Sie kommen so unschuldig wie normal daher, doch sie ziehen Verständlichkeit und Testbarkeit drastisch herunter. Funktionale Abhängigkeiten existieren immer dort, wo Logik in einer Funktion mit Aufrufen anderer Funktionen wechselt.

Das ist das vorherrschende Muster in der Codierung von Funktionen und liegt unterhalb des Radars der Architekturempfehlungen. Sie erkennen es als gegeben an und versuchen lediglich, seinen negativen Einfluss zu reduzieren. Das halte ich für nicht mehr akzeptable, weil dadurch Klarheit verlorengeht. Die schwierige Testbarkeit wird nur symptomatisch behandelt; der Behandlungsansatz steigert die Komplexität. Insgesamt leidet die Wandlungsfähigkeit.

Dem stelle ich mit der IODA Architektur einen Vorschlag gegenüber, der das Übel an der Wurzel packt. In der IODA Architektur gibt es keine funktionalen Abhängigkeiten mehr - und damit verschwinden die daraus folgenden Friktionen. Die Verständlichkeit steigt, denn die IODA Architektur führt ganz natürlich zu (sehr) kleinen Funktionen. Die Testbarkeit steigt, weil der hauptsächlich zu testende Code ohne Abhängigkeiten und leicht zugänglich ist.

In diesem Band sind drei Artikel aus der .NET Fachzeitschrift dotnetpro versammelt, die die IODA Architektur am Beispiel erklären. Zunächst stelle ich bisherige Architekturmuster theoretisch und mit Code vor, dann kontrastiere ich sie mit einer Implementation nach IODA Architektur.

Die Erstausgabe der Artikel war 2018. Seitdem hat sich die IODA Architektur weiterentwickelt. Deshalb findet sich am Ende ein Update einiger Aspekte.

Bei der IODA Architektur steht wie bei den moderneren konzentrischen Architekturmustern die Domäne im Mittelpunkt. Doch Domäne und periphere Funktionsbereiche sind nicht miteinander direkt "verdrahtet". Diese Unabhängigkeit basierend auf Prinzipien abgeleitet aus der ursprünglichen Objektorientierung nach Alan Kay macht Code strukturiert nach IODA Architektur leichter verständlich und besser testbar.

Ver. 1.0.1.20201227