Vorwort

Seit Ende der 1990er befasse ich mich mit Softwarearchitektur explizit. Vorher hatte ich Software einfach “irgendwie zusammengeschraubt”, glaube ich. Das hatte genügend gut geklappt, so dass ich damit Geld verdienen konnte; die Kunden der Firma, die ich mit meinem Geschäftspartner hatte, waren zufrieden mit unserer Software.

Doch dann irgendwann war das nicht mehr genug. In die Microsoft-Bubble, in der ich mich damals befand, drang etwas Neues ein. Entwurfsmuster für die Objektorientierung waren angesagt und dann kam sogar Microsoft als Technologiehersteller mit Empfehlungen für die Strukturierung von Software um die Ecke. Ich erinnere mich ans Schichtenmodell, dann an N-Tier Architecture, dann an Emissaries and Executants (ich glaube, so hieß das eine Zeit lang)… Auch wenn die Details verschwimmen, eines habe ich noch im Gefühl: Softwarearchitektur war wichtig geworden.

Wie es dann so kam, hat mich das Thema nicht wieder verlassen. Ich war vom Technologieanwender zu einem “Planer” von Technologieanwendung geworden.

Allerdings konnte ich schon bald nicht mehr einfach akzeptieren, was an Architekturmustern empfohlen wurde. Immer fehlte irgendetwas oder kam mir nicht plausibel vor. Anfang 2005 habe ich dieses Gefühl dann so ernst genommen, dass ich anfing, an einem eigenen Architekturmodell zu tüfteln. Die Softwarezelle ward geboren. Hier zwei Bilder aus dieser Zeit, mit denen ich das Konzept in meinem damaligen Blog erklärt und entwickelt habe:¹

Damals war mir sehr wichtig, die Geschäftslogik in den Mittelpunkt zu rücken. Sie schien mir in anderen Architekturmustern zu wenig betont und gerade für verteilte Anwendungen stiefmütterlich behandelt.²

Außerdem fand ich die ganze Herangehensweise an die Strukturierung von Software zu technisch, zu mechanisch. Wenn Software entwickelt wird, sich also entwickelt, über lange Zeit entwickelt, geradezu eine Evolution durchläuft… dann, so war mein Gedanke, sollte sie durch ein organischeres Bild beschrieben werden. Deshalb der Begriff Softwarezelle. Mit ihr, aus ihr wollte ich Software wachsen sehen.

Vielleicht entstand damals mein Interesse für nachhaltige Softwareentwicklung, das später zur Mitgründung der Clean Code Developer Initiative geführt hat. Mein Empfinden war einfach, dass viele Entwickler sich redlich bemühten, das eine oder andere Architekturmuster anzuwenden, um nicht zu schnell in die “Unwartbarkeit” zu laufen. Doch dieses Bemühen war zu selten von Erfolg gekrönt. Die Anwendung der Muster funktionierte nicht wie gewünscht, was immer wieder zu Frust geführt hat und der wiederum zu einer Hoffnung, dass Technologie das Dilemma doch bitte lösen möge.

Doch Technologie nimmt uns in der Softwareentwicklung das Nachdenken nicht ab - außer vielleicht in Sonderfällen. Wir müssen weiterhin verstehen und entscheiden. Und für das Entscheiden brauchen wir Heuristiken, Prinzipien, Konzepte.

Seitdem hat mich das Thema Softwarearchitektur also nicht losgelassen. Bei aller trivialen Korrektheit des Beraterspruchs “Es kommt darauf an…” glaube ich, dass es einen Rahmen gibt, in dem sich Softwarearchitektur bewegen sollte. Die konkrete Architektur eines Softwaresystems orientiert sich nur daran, sie prägt ihn individuell im Hinblick auf die nicht-funktionalen Anforderungen aus. Dabei kommt es natürlich darauf an, wie man das tut.

Doch es kommt eben nicht darauf an, dass man es tut. Softwarearchitektur ausgehend von Prinzipien und Mustern nicht explizit zu betreiben, halte ich für keine Option.

Aber welche Prinzipien und Muster? Darüber habe ich lange nachgedacht. Die Beschäftigung mit dem Clean Code Development hat mir dabei geholfen. Das eine hat das andere befruchtet. Deshalb spreche ich heute auch weniger von Clean Code; meine Trainings laufen unter einer anderen Überschrift, um den Bogen weit genug spannen zu können. Denn worum geht es? Um langfristig hohe Produktivität.

Softwarearchitektur ist ein Aspekt des Wunsches, Software über möglichst lange Zeit möglichst anpassungsfähig (wandelbar) zu halten. Andere Aspekte gehören auch dazu: konsequente test-first Codierung, inkrementelle Anforderungsanalyse und Umsetzung, Zurückhaltung bei der Veränderung von Produktionscode, Verzicht auf die Aufwandsschätzung zugunsten von Vorhersagen usw.

Clean Code hat Appeal für Entwickler, nicht für Manager. Es ist damit ein zu techschnischer Begriff für das, worum es geht. Programming with Ease hingegen spannt für mich einen Bogen, der einerseits weit genug ist und andererseits spezifisch genug. Ich möchte die Programmierung rundum erleichtern. Dazu gehört auch, die grobe Strukturierung von Code. Denn wer keine grundlegende Vorstellung von der Anatomie von Software hat, von ihren wiederkehrenden Funktionsbausteinkategorien und deren Zusammenhänge, der tut sich von Anfang an schwer mit jedem Softwareprojekt. Und dabei geht es noch nicht einmal um die Erfüllung spezieller nicht-funktionaler Anforderungen. Nein, es reicht schlicht Testbarkeit und Wandelbarkeit auch bei einem Monolithen, d.h. nicht verteilter Software, hoch halten zu wollen. Das ist Problem genug, um stets nach besseren Ansätzen zu suchen.

Das habe ich getan und tue es noch mit der IODA Architektur. Mit ihr stelle ich das, was mit Softwarezellen begonnen hat, auf ein Prinzipienfundament. Die Hexagonal Architecture und die Clean Architecture basieren auf den Prinzipien DIP/IoC. Die IODA Architektur basiert auf IOSP und PoMO als Ergebnisse einer Analyse der ursprünglichen Objektorientierung, wie sie Alan Kay 1968 gedacht hatte.³

Ich habe nichts gegen DIP/IoC. Im Gegenteil! Aber für mich ist da eben nicht Schluss. Für testbarere und wandelbarere Software brauchen wir ein Architekturmuster, das darüber hinaus geht.

Mir scheint, dass ich 2015 das erste Mal den Begriff IODA Architektur in einem Blogartikel benutzt hatte. 2018 habe ich den aktuellen Stand dazu dann in drei Artikeln in der dotnetpro zusammengefasst. Diese Artikel sind in diesem kleinen Buch zusammengefasst, um die Lektüre einfacher und unabhängig von einem Abonnement der dotnetpro zu machen. Vielen Dank an Chefrefakteur Tilman Börner und die Ebner Media Group, eine solche herausgelöste Veröffentlichung zu ermöglichen. Natürlich habe ich diese Gelegenheit genutzt, die Artikel durchzusehen, hier und da zu ergänzen und am Ende noch ein Update hinzuzufügen, das einzuarbeiten schwierig gewesen wäre. Ich hoffe, auf diese Weise diese Perspektive auf Softwarearchitekturmuster einem größeren Interessentenkreis zugänglich zu machen.

Viel Spaß bei der Lektüre!

-Ralf Westphal, Bansko/Bulgarien im Dezember 2020