\n3 - IODA am Beispiel

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/ioda-architektur-im-vergleich-dnp.

\nStruktur fraktal

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/ioda-architektur-im-vergleich-dnp.

\nZusammenfassung

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/ioda-architektur-im-vergleich-dnp.

",{"_185":186,"_44":45,"_48":49,"_46":47,"_70":71,"_187":188,"_214":183},"previewContent","

Inhaltsverzeichnis

\n Vorwort\n
\n 1 - Eine Kritik bisheriger Architekturmodelle\n
- \n Am Anfang war der Monolith\n
- \n Den Monolithen in Schichten spalten\n
- \n Schichten entkoppeln\n
- \n Schichten in Schale werfen\n
- \n Reflexion\n
\n
\n 2 - Das IODA Architekturmodell\n
- \n Funktionale Abhängigkeiten als Wurzelproblem\n
- \n Auflösung funktionaler Abhängigkeiten\n
- \n Operationen verbinden\n
- \n Verbindung zur Außenwelt\n
- \n Ein neues Architekturmuster\n
- \n Echt abstrakt\n
\n
\n 3 - IODA am Beispiel\n
- \n Struktur fraktal\n
- \n Zusammenfassung\n
\n
\n Update 2020\n
- \n Logik frisch definiert\n
- \n Integrationen konsequent benannt\n
  - \n Interactor\n
  - \n Processor\n
  - \n Interactor-Varianten\n
  \n
- \n Reflexion\n
\n
\n Anmerkungen\n

\nVorwort

\n\n

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.

\n\n

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.

\n\n

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

\n\n

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:¹

\n\n

\"\" — Eine frühe Form der Softwarezelle aus dem April 2005

\n\n\n

\"\" — Softwarezellen im Verbund für eine verteilte Architektur

\n\n\n

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.²

\n\n

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.

\n\n

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.

\n\n

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.

\n\n

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.

\n\n

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.

\n\n

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.

\n\n

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.

\n\n

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.

\n\n

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.³

\n\n

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.

\n\n

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.

\n\n

Viel Spaß bei der Lektüre!

\n\n

-Ralf Westphal, Bansko/Bulgarien im Dezember 2020

\n\n\n

\n1 - Eine Kritik bisheriger Architekturmodelle

\n\n

Ich kann sie nicht mehr hören die Anpreisungen des Architekturmusters „Schichtenmodell“. In der dotnetpro wie anderswo spukt es immer wieder als klassische und deshalb gute Organisation von Code herum. Mir scheint das inzwischen ein Fall von Cargo Kult: Irgendwer hat irgendwann seinen Code so strukturiert und damit einen Vorteil erlangt – und nun folgen dem Generationen von Entwicklern blind.

\n\n

Was aber, wenn sich die Welt weitergedreht hat? Was, wenn man da etwas mechanisch tut, ohne wirklich konsequent über die ursprünglichen Beweggründe nachzudenken? Das Ergebnis ist dann immer gleich: Es entsteht Unwohlsein, die Dinge werden schwierig – doch man weiß nicht so recht, woher das kommt. Man macht doch alles richtig, oder? Eher wohl nicht; vielleicht muss man sich einfach noch mehr bemühen. Also die Anstrengungen verdoppeln, das Muster einzuhalten. Und so entsteht dann noch mehr Unwohlsein.

\n\n

„Been there, done that, got the t-shirt“, kann ich dazu sagen. Einst war ich auch Anhänger des Schichtenmodells und anderer seiner mustergültigen Geschwister. Doch irgendwann habe ich für mich realisiert: der Schmerz ist größer als der Nutzen. Ich muss die Muster nicht besser anwenden, sondern einen anderen Weg suchen, meine Software zu strukturieren.

\n\n

Worauf ist dann gestoßen bin, davon möchte ich Ihnen im Folgenden berichten. Es ist eine Geschichte der Erleichterung. Softwareentwicklung macht mir jetzt wieder Spaß. Ich kann mich viel mehr auf die Lösung der Probleme konzentrieren, weil die Struktur mich nicht mehr in ein hinderliches Korsett zwängt.

\n\n

Aber der Reihe nach. Lassen Sie mich noch vor dem “Musterspuk” beginnen.

\n\n

\nAm Anfang war der Monolith

\n\n

Hier ist eine Challenge:

\n\n\n\n

Das ist eine simple Aufgabe, denke ich. Dennoch ist da alles drin, was eine Software ausmacht: ein bisschen Benutzerschnittstelle, ein bisschen Fachlogik, ein bisschen Datenzugriff. Genug, um darauf das Schichtenmodell und andere Strukturierungsideen anzuwenden.

\n\n

In diesem Beispiel geht es nicht darum, ein Technologiefeuerwerk abzubrennen. Eine Konsolenanwendung reicht völlig aus. Deren Anwendung könnte so aussehen:

\n\n\n

1 $ wordcount.exe\n2 Text eingeben: Es blaut die Nacht, die Sternlein blinken\n3 6 Worte, davon 5 verschieden\n4 $ wordcount.exe gedichtanfang.txt\n5 6 Worte, davon 5 verschieden\n6 $\n

\n\n\n\n\n

Der eingegebene Text hat zwar 7 Worte, doch das Wort „es“ steht in der Datei mit den Stoppworten und wird deshalb nicht gezählt. Außerdem steht „die“ im Text zweimal, daher unterscheidet sich die Zahl der Worte von der der verschiedenen.

\n\n

Sie können ja mal als Fingerübung selbst für die Challenge ein Programm schreiben. Beobachten Sie sich dabei: Wie gehen Sie vor? Wie strukturieren Sie den Code und warum?

\n\n

Wenn Sie mitmachen und später vergleichen möchten, dann lesen Sie erstmal nicht weiter. Spoileralarm! Denn ich möchte Ihnen verschiedene „hoch entwickelte“ Lösungen vorstellen, um daran zu zeigen, warum das Schichtenmodell und Verwandte keine Option mehr für mich sind.

\n\n

Aber zuerst eine Lösungsvariante, die gar nicht mehr geht. Oder ist sie eine, die womöglich noch häufig anzutreffen ist? Entscheiden Sie, ob Ihnen solcher Code wie in Abbildung 1 immer noch über den Weg läuft.

\n\n

Den Code bezeichne ich als monolithisch: Nicht nur ist er nicht verteilt, er besteht auch nur aus Logik. Rekombinierbare Strukturelemente wie Funktionen oder Klassen sind vernachlässigbar. Der Code ist also quasi strukturlos aus architektonischer Sicht.

\n\n

Die Anweisungen in der einzigen Funktion Main(), d.h. die Logik, tut zwar, was sie tun soll: das Programm ist funktional; doch verständlich oder testbar ist die Logik nicht.

\n\n

\"\" — Abbildung 1: Eine funktionale Lösung mit unwesentlicher Struktur

\n\n\n

Sicher, das sind kaum 50 Zeilen. Die zu verstehen, sollte doch kein Problem sein. Warum sich hier mehr Aufwand mit mehr Struktur machen?

\n\n

Erstens ist das hier ein Beispiel mit überschaubarer Funktionalität (und auch noch eigentlich geradliniger Logik), um eben Strukturierungsansätze zu demonstrieren. Selbst wenn das später ein bisschen künstlich und overengineert aussehen sollte, wird es hoffentlich die wesentlichen Punkte illustrieren helfen, um die es mir geht.

\n\n

Zweitens glaube ich, dass wir viel sensibler sein sollten, was die Strukturierung angeht. Wir sollten uns nicht überschätzen in der Fähigkeit, Code zu verstehen. Die Zeit für einen Bugfix oder zum Einbau einer Erweiterung ist immer knapp. Jede Minute, die wir beim Verstehen von Code sparen können, bevor wir ihn verändern, ist wichtig. Dafür aber müssen wir vorher, schon beim Schreiben etwas tun. Der Code-Autor muss an den späteren Code-Leser denken.

\n\n

\n
“Programs must be written for people to read, and only incidentally for machines to execute.”, Harold Abelson & Gerald Jay Sussman
\n

\n\n

Was macht den Code in Abbildung 1 aber so schwer zu verstehen? Es ist die kunterbunte Vermischung von Verantwortlichkeiten.

\n\n

In Abbildung 2 habe ich die wesentlichen Verantwortlichkeiten farblich hervorgehoben. Sie sehen, das ist ein Flickenteppich. Verantwortlichkeiten sind verstreut über die Logik. Verantwortlichkeiten werden mit Kontrollstrukturen „geöffnet“, um dann andere dazwischen zu schieben und sie erst später zu „schließen“.

\n\n

\"\" — Abbildung 2: Unstrukturierter Code ist ein Flickenteppich aus Verantwortlichkeiten

\n\n\n

So kann kein Fluss des Verständnisses entstehen. Der Code „erzählt keine Story“, in der etwas entlang einer Kausalkette passiert. Es fehlen Bedeutungseinheiten, die Sie auf einen Blick erfassen können. Alles müssen Sie sich durch Simulation der Ausführung der Anweisungen erst erschließen.

\n\n

Das ist gruselig aufwändig und fehlerträchtig. Und ob der Code wirklich korrekt ist, lässt sich nicht ermitteln, ohne ihn manuell auszuführen. Keine der Verantwortlichkeiten kann gezielt mit automatisierten Tests überprüft werden. So lässt sich nicht zügig feststellen, ob der Code schon reif zur Auslieferung ist oder nach einer Änderung immer noch korrekt, also regressionsfrei.

\n\n

So geht’s nicht. Da sind wir uns einig, hoffe ich.

\n\n

Aber das war die Situation zumindest früher auch nach Einführung der Strukturierten Programmierung. Vor diesem Hintergrund sind die ersten Architekturmuster entstanden. Zunächst Model-View-Controller (MVC), dann das Schichtenmodell. Was für ein Sonnenaufgang über dem Monolithen.

\n\n

\nDen Monolithen in Schichten spalten

\n\n

MVC, Schichtenmodell, Hexagonale Architektur und auch die Clean Architecture verfolgen alle denselben Ansatz:

\n\n

Sie definieren einen Kanon von Verantwortlichkeiten und verordnen die Spaltung der Logik nach diesen Verantwortlichkeiten in Module.
Sie geben genau vor, wie die Module in Beziehung stehen, d.h. einander kennen und nutzen dürfen.

\n\n

Die Beliebtheit des Schichtenmodells scheint mir hierbei in einer Kombination aus leicht zu verstehenden Verantwortlichkeiten in angenehmer Granularität und sehr klaren Beziehungen zu bestehen (Abbildung 3).

\n\n

\"\" — Abbildung 3: Das Schichtenmodell definiert verständliche Verantwortlichkeiten in klaren Beziehungen

\n\n\n

Wenn ich dieses Muster auf den bisherigen Code zur Lösung der obigen Challenge anwende, dann ist damit tatsächlich etwas gewonnen: Verständlichkeit. Die Logik liegt nicht mehr auf einem Haufen, sondern ist verteilt auf Klassen als Module, so dass sich schon beim Betrachten des Projektes eine gewisse Übersicht einstellt (Abbildung 4).

\n\n

\"\" — Abbildung 4: Schichten steigern die Übersichtlichkeit

\n\n\n

Wer mit dem Schichtenmodell vertraut ist, sieht hier erstens Verantwortlichkeiten, unter denen er sich etwas vorstellen kann. Zweitens sind dem Betrachter sofort die grundsätzlichen Beziehungen klar. Das ist ja auch der Sinn der Einhaltung eines solchen Musters. Sie müssen kein Rad neu erfinden, sondern können sich darauf verlassen, dass Sie nichts grob falsch machen, wenn Sie nach dem Schema strukturieren. Mit einem Architekturmuster setzen Sie eine Brille auf, durch die Sie die Logik analysieren können; was Sie dabei identifizieren, stecken Sie in die kanonischen Module. Und Sie können auch noch annehmen, dass ein anderer Entwickler, der auch das Muster kennt, ihre Struktur versteht; er findet sich darin also von vornherein leicht(er) zurecht.

\n\n

Die nächste Abbildung zeigt konkret die Schichtung der Klassen der Umsetzung aus Abbildung 4. Ordentlich, oder? Eine so organisierte Codebasis macht Freude. Alles hat seinen Platz. Da wissen Sie genau, wo was passiert.

\n\n

\"\" — Abbildung 5: Konkrete Schichtung der Anwendungslogik

\n\n\n

Ja, damit ist etwas gewonnen. Es ist besser als vorher, aber noch nicht wirklich gut. Denn schauen Sie sich einmal den Code der Businesslogik an:

\n\n

\"\" — Abbildung 6: Schlecht testbare Logik trotz Schichtung

\n\n\n

Die groben Verantwortlichkeiten sind grundsätzlich hübsch getrennt, die Abhängigkeiten sind sauber ausgerichtet – doch gut testbar ist deshalb die eigentliche Businesslogik immer noch nicht. Denn die Businesslogik hängt immer noch von der Datenzugriffslogik ab. Es besteht eine funktionale Abhängigkeit: Logik in einer Methode ruft eine andere Methode auf, um zwischendurch deren Logik auszuführen.

\n\n

Das hört sich normal an und findet sich bestimmt in Ihrem Code auch allerorten. Doch das macht es nicht besser. Solche funktional abhängige Logik ist schlicht nicht für sich allein testbar.

\n\n

Natürlich ist die Logik in Abbildung 6 auch in anderer Hinsicht noch suboptimal. Doch das ist sekundär für den Punkt, um den es mir hier im Augenblick geht. Ich habe nur das minimal Nötige getan, um den monolithischen Code nach dem Schichtenmodell zu strukturieren. Das fundamentale Problem des Schichtenmodells geht nicht weg, wenn ich die Wortzählungslogik noch weiter refaktorisiere. Der Klumpen in Count_words() dient also der Unterstreichung des grundsätzlich zu lösenden Problems der funktionalen Abhängigkeiten.

\n\n

Wer die Businesslogik testen will, der kann das im Moment trotz oder wegen Schichtenmodell nur tun, indem er ebenfalls die Logik der Datenzugriffsschicht ausführt. Das macht einen Businesslogik-Test langsamer und/oder umständlicher, weil eine Datei als Ressource bereitgestellt werden muss.

\n\n

Nicht wirklich dramatisch in diesem trivialen Beispiel, doch wenn Sie sich das Szenario umfangreicher denken… dann kommt schon etwas zusammen an Overhead.

\n\n

Wenn Abbildung 1 den Bewusstseinsstand in Sachen Anwendungsarchitektur bis Mitte der 1990er in vielen Projekten widerspiegelt, dann steht Abbildung 6 für den Ende der 1990er.

\n\n

\nSchichten entkoppeln

\n\n

In einer Co-Evolution mit bewussterer Anwendungsstrukturierung befand sich ab Ende der 1990er das Thema Testen. Die ersten Unit Testing Frameworks kamen auf.

\n\n

Wo klare Verantwortlichkeiten in Modulen freigestellt waren, konnten überhaupt erst automatisierte Tests feingranular ansetzen. Aber um in einer sauberen Hierarchie automatisierte Tests punkgenau nur gewisse Logik testen lassen zu können, brauchte es Entkopplung der Verantwortlichkeiten.

\n\n

Auftritt DIP: Mit dem Dependency Inversion Principle wurde es möglich, Tests auf eine Schicht zu fokussieren.

\n\n

Der Trick besteht darin, Compilezeitabhängigkeiten von Laufzeitabhängigkeiten zu trennen. Zur Compilezeit besteht nach DIP keine direkte funktionale Abhängigkeit von Logik einer Schicht zu Logik einer anderen. Eine obere Schicht hängt nicht von einer konkreten unteren ab, sondern lediglich von einer Abstraktion:

\n\n

\"\" — Abbildung 7: Mit dem DIP werden Schichten entkoppelt

\n\n\n

Abstraktionen sind gewöhnlich Interfaces oder abstrakte Klassen. Die können von der niedrigen Schicht implementiert werden – aber man kann auch eine Attrappe für eine niedrige Schicht so aussehen lassen. Doch eins nach dem anderen.

\n\n

Zuerst die Anwendung mit verbesserter Schichtenarchitektur in im Überblick. Hinzugekommen sind die Interfaces für die Module der bisherigen Schichten:

\n\n

\"\" — Abbildung 8: Eine Schichtenarchitektur mit DIP

\n\n\n

Der geübte Softwerker lässt beim Anblick dieser Module sogleich vor seinem geistigen Auge ein Beziehungsgeflecht wie entstehen und weiß: alles hübsch entkoppelt und testbar.

\n\n

\"\" — Abbildung 9: Über Interfaces entkoppelte Schichten

\n\n\n

Und was ist der Nutzen des ganzen Aufwands? Im nächsten Codeausschnitt sehen Sie, wie nun mit einer Attrappe die Businesslogik unabhängig von darunterliegenden Details getestet werden kann. Die Implementation der aufrufenden Logik ist von der aufgerufenen durch das Interface entkoppelt; erst zur Laufzeit wird bestimmt, wer aufgerufen wird.

\n\n

Statt einen Datenzugriff konkret zu durchlaufen, werden die Stoppworte im Test hart verdrahtet. Das ist trivial in puncto Laufzeit und Komplexität und einfacher, als eine Stoppwortdatei zu benutzen.

\n\n

\"\" — Abbildung 10: Mit einer Attrappe wird das Testen von abhängiger Logik einfach

\n\n\n

Dass der Businesslogik aber überhaupt eine Attrappe untergeschoben werden kann, ist der Anwendung des Inversion of Control (IoC) Prinzips geschuldet. Dessen Manifestation besteht hier im Hineinreichen der Laufzeitabhängigkeit in die Businesslogik durch ihren Konstruktor (*constructor injection).

\n\n

\"\" — Abbildung 11: Injizieren der konkreten Implementation einer abstrakten Abhängigkeit zur Laufzeit

\n\n\n

Die Abhängigkeit vom Interface IDataaccess zur Compilezeit wird zur Laufzeit durch die Injektion einer Implementation des Interfaces befriedigt. Nachfolgende sind die Compilezeit- und Laufzeitabhängigkeiten zusammen visualisiert.

\n\n

\"\" — Abbildung 12: Mit DIP unterscheiden sich die Abhängigkeiten zu Compilezeit und Laufzeit

\n\n\n

Das sieht jetzt schon nicht mehr so einfach aus wie das ursprüngliche Schichtenmodell, würde ich sagen. Logik ist auch im Schichtenmodell bei vortrefflicher Ausrichtung der Beziehungen immer noch funktional abhängig. Um trotz dieser Abhängigkeiten Testbarkeit zu erlangen, müssen zusätzliche Elemente eingeführt werden: Abstraktionen (hier: Interfaces). Und aus einer Menge unidirektionaler Abhängigkeiten werden zwei Mengen, von denen eine auch noch gegenläufige Abhängigkeiten enthält.

\n\n

Das scheint der Preis der Wandelbarkeit zu sein. Verständlichkeit entsteht durch Trennung von Verantwortlichkeiten und klare Beziehungen. Testbarkeit entsteht durch DIP und IoC. Ist halt so. Da müssen wir durch.

\n\n

Um das Leben nun wenigstens aber ein wenig einfacher zu machen, gibt es Mock-Frameworks wie Moq (in Abbildung 10 benutzt) und Dependency-Injection-Frameworks wie Simple Injector oder Unity.

\n\n

Jetzt ist es nur noch eine Sache konsequenter Anwendung von Prinzipien und Werkzeugen, um sauberen Code zu schreiben. Alles scheint gesagt zur grundlegenden Strukturierung von Logik.

\n\n

Das ist zumindest der Stand des Bewusstseins, den ich bei Clean Code Development Trainings. Wenn ein Architekturmuster bekannt ist, dann ist es MVC oder das Schichtenmodell. Zusätzlich wird dann noch die Fahne der SOLID-Prinzipien hochgehalten, zu denen das DIP gehört wie auch das SRP (Single Responsibility Principle), das sich mit Verantwortlichkeitstrennung befasst.

\n\n

Nur leider sehe ich ebenfalls bei den Teams, die Code SOLIDe in Schichten strukturieren keine entspannten und freudvollen Gesichter. Der Code ist immer noch schwer zu wandeln. Sonst würde man mit mir ja auch nicht über Clean Code Development sprechen wollen.

\n\n

Wie kann das aber sein? Trotz sauberer Schichtung immer noch nicht sauber? Merkwürdig, oder?

\n\n

\nSchichten in Schale werfen

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/ioda-architektur-im-vergleich-dnp.

\n\n\n

\nReflexion

\n\n

Früher war nicht alles besser. Codezustände wie in Abbildung 1 will niemand (wieder) haben.

\n\n

Die erste Variante des Schichtenmodells jedoch, die war gar nicht so schlecht. Die klare Trennung von Verantwortlichkeiten kombiniert mit einer konsequenten Ausrichtung der Abhängigkeiten hat die Verständlichkeit deutlich gesteigert (Abbildungen 4 und 5).

\n\n

Für gute Wandelbarkeit war das allerdings noch nicht genug. Die braucht nicht nur Verständlichkeit, sondern auch Testbarkeit. Die war in der ersten Schichtenvariante noch begrenzt. Lediglich die Logik der untersten Schicht war gut testbar, weil sie für sich stand. Die Logik in den darüber liegenden Schichten konnte zwar grundsätzlich schon gezielt angesprochen werden, nur musste dann auch immer die Logik darunter liegender Schichten beim Test mit durchlaufen werden. Das kostet Zeit und das macht es nicht leicht, einen Bug zu lokalisieren.

\n\n

Die Testbarkeit ist dann in der zweiten Variante des Schichtenmodells (Abbildungen 8 und 9) nachgezogen worden. Durch Anwendung von DIP und IoC können für Tests untere Schichten ausgeblendet werden. Wenn etwas schiefgeht, dann weiß man, dass der Fehler in der Logik der zu testenden Schicht steckt.

\n\n

Allerdings: Dieser Fortschritt in der Testbarkeit hat seinen Preis. Der wird deutlich in der Clean Architecture Variante (Abbildungen 15 und 19). DIP und IoC addieren Komplexität, die die Verständlichkeit nun – zumindest nach meinem Empfinden – massiv reduziert. Man ist über das Ziel hinausgeschossen. „Mehr vom Selben“ (hier: DIP und IoC) hat den Fortschritt, den die zweite Variante des Schichtenmodells gebracht hat, nicht vergrößert. Im Gegenteil!

\n\n

Aber wie kommt das? Ich glaube, es liegt daran, dass man zu sehr auf die Compilezeitabhängigkeiten gestarrt hat.

\n\n

Von der Schichtung zur Konzentrik überzugehen hat etwas mit dem Compilezeitabhängigkeiten zu tun. Im Schichtenmodell war das Volatile (oder Instabile), Robert C. Martins „mechanisms“, nicht konsequent in einer Position, wo Veränderungen wenig Probleme machen.

\n\n

Relativ problemlos sind Veränderungen nämlich dort, wovon nur wenige oder keine Codeeinheiten abhängig sind. Im Schichtenmodell ist das nur für die Präsentationslogik der Fall. Die Datenzugriffslogik hingegen, die ebenfalls ein „mechanism“ ist, muss wegen der Abhängigkeit anderer von ihr, Stabilität zusichern.

\n\n

Das wurde mit der Clean Architecture bewusst verändert. Dort sind nicht nur die Abhängigkeiten sauber ausgerichtet, sondern auch die Verantwortlichkeiten nach Stabilität positioniert: am stabilsten sind ganz allgemeine, grundlegende Regeln im Kern, am instabilsten die Kommunikation mit der Umwelt in der äußeren Schale.

\n\n

Diese Sichtweise gefällt mir – allerdings hat die Implementation eben einen hohen Preis. Abbildungen 17 und 20 machen es exemplarisch deutlich: die Verständlichkeit der Zusammenhänge im Code sinkt.

\n\n

Aber selbst wenn ich einmal über den auch von Robert C. Martin beklagten Mehraufwand hinwegsehe, frage ich mich, was wirklich gewonnen ist. Denn Abbildung 21 zeigt ein Bild, das sich im Grunde nicht vom Schichtenmodell unterscheidet. Zur Laufzeit ist eine Businesslogik immer noch vom Datenzugriff abhängig.

\n\n

Was soll das? Da mag zur Compilezeit die Abhängigkeit umgekehrt sein – Adapter außen hängt von Domäne innen ab –, doch zur Laufzeit gehen die Aufrufe dorthin durch die Domäne in die Tiefe.

\n\n

Es ist letztlich nichts gewonnen. Die Abstraktion, von der die Businesslogik abhängig ist, ist lediglich verschoben worden. Vorher gehörte sie zur darunterliegenden Schicht (IDataaccessLayer in Abbildung 9), jetzt gehört sie zur Businesslogik selbst (siehe IStopwords in Abbildung 19).

\n\n

Dass nichts gewonnen ist, ist deutlich zu bemerken beim Testen. Das Architekturbild suggeriert, dass eine innere Schale keine Abhängigkeit hat zu einer äußeren – doch beim Testen stellt sich das Gegenteil heraus. In Abbildung 17 ist der Use Case Interactor – also Code der Use-Case-Schale – zur Laufzeit abhängig vom Presenter in der darüberliegenden Schale. Dass der Use Case Output Port zur Use-Case-Schale gehört, kaschiert das nur. Im Test muss trotzdem eine Attrappe gebaut werden.

\n\n

Sind Sie noch da oder haben Sie schon halb abgeschaltet? Das würde mich nicht wundern. Bei dem ganzen hin und her der Abhängigkeiten von Compilezeit und Laufzeit, kann einem schon der Kopf schwirren. Ich jedenfalls verliere bei der Darstellung der vollständigen Abhängigkeiten der implementierten Clean Architecture den Überblick (Abbildung 22).

\n\n

So sieht für mich ein Testalbtraum aus. Ganz zu schweigen davon, dass damit das Rätselraten darum, für welche Klassen ein Interface definiert werden sollte, weiter angeheizt wird. Im Zweifelsfall lautet dann die Antwort „Für alle!“ und damit explodiert die Zahl der Dateien in einem Projekt (wenn man je Klasse und je Interface eine Datei denkt).

\n\n

\"\" — Abbildung 22: Das vollständige Abhängigkeitsbild der implementierten Clean Architecture

\n\n\n

Das einzig Positive, das ich der Clean Architecture abgesehen vom hübschen Bild abgewinnen kann, ist die Tendenz zur Aufspaltung von Abstraktionen. Sie scheint die Anwendung des Interface Seggregation Principle (ISP) nahezulegen. Schmalere Interfaces helfen einfach bei der Entkopplung.

\n\n

Wo vorher nur eine Präsentationslogikschicht und eine Datenzugriffsschicht mit respektiven Abstraktionen waren, sind beide nun zerfallen in mehrere Teile: Controller und Presenter sind getrennt und es gibt IPresenter; ebenfalls getrennt sind IText und IStopwords, wo vorher nur IDataAccessLayer war.

\n\n

Am Ende ist dieser positive Effekt für mich jedoch nicht ausschlaggebend. Viel wichtiger finde ich das Sinken der Verständlichkeit durch eine gestiegene Artefaktzahl und den weiterhin hohen Testaufwand. Denn jede Laufzeitabhängigkeit ruft zur Testzeit nach einer Attrappe.

\n\n\n

\n2 - Das IODA Architekturmodell

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/ioda-architektur-im-vergleich-dnp.

\n\n\n

\nFunktionale Abhängigkeiten als Wurzelproblem

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/ioda-architektur-im-vergleich-dnp.

\n\n\n

\nAuflösung funktionaler Abhängigkeiten

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/ioda-architektur-im-vergleich-dnp.

\n\n\n

\nOperationen verbinden

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/ioda-architektur-im-vergleich-dnp.

\n\n\n

\nVerbindung zur Außenwelt

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/ioda-architektur-im-vergleich-dnp.

\n\n\n

\nEin neues Architekturmuster

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/ioda-architektur-im-vergleich-dnp.

\n\n\n

\nEcht abstrakt

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/ioda-architektur-im-vergleich-dnp.

\n\n\n

\n3 - IODA am Beispiel

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/ioda-architektur-im-vergleich-dnp.

\n\n\n

\nStruktur fraktal

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/ioda-architektur-im-vergleich-dnp.

\n\n\n

\nZusammenfassung

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/ioda-architektur-im-vergleich-dnp.

\n\n\n

\nUpdate 2020

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/ioda-architektur-im-vergleich-dnp.

\n\n\n

\nLogik frisch definiert

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/ioda-architektur-im-vergleich-dnp.

\n\n\n

\nIntegrationen konsequent benannt

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/ioda-architektur-im-vergleich-dnp.

\n\n\n

\nInteractor

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/ioda-architektur-im-vergleich-dnp.

\n\n\n

\nProcessor

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/ioda-architektur-im-vergleich-dnp.

\n\n\n

\nInteractor-Varianten

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/ioda-architektur-im-vergleich-dnp.

\n\n\n

\nReflexion

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/ioda-architektur-im-vergleich-dnp.

\n\n\n

\nAnmerkungen

Vorwort

\n\n

\n\n","tocStructure",[189,190,191,192,193,194,195,196,197,198,199,200,201,202,203,204,205,206,207,208,209,210,211,212,213],{"_81":82,"_44":83,"_75":-5,"_84":85,"_77":86,"_98":-5,"_99":-5,"_89":-5},{"_81":82,"_44":91,"_75":-5,"_84":92,"_77":86,"_98":-5,"_99":-5,"_89":-5},{"_81":95,"_44":96,"_75":-5,"_84":97,"_77":86,"_98":-5,"_99":-5,"_89":-5},{"_81":95,"_44":101,"_75":-5,"_84":102,"_77":86,"_98":-5,"_99":-5,"_89":-5},{"_81":95,"_44":104,"_75":-5,"_84":105,"_77":86,"_98":-5,"_99":-5,"_89":-5},{"_81":95,"_44":107,"_75":-5,"_84":108,"_77":86,"_98":-5,"_99":-5,"_89":-5},{"_81":95,"_44":110,"_75":-5,"_84":111,"_77":86,"_98":-5,"_99":-5,"_89":-5},{"_81":82,"_44":113,"_75":-5,"_84":114,"_77":86,"_98":-5,"_99":-5,"_89":-5},{"_81":95,"_44":117,"_75":-5,"_84":118,"_77":86,"_98":-5,"_99":-5,"_89":-5},{"_81":95,"_44":120,"_75":-5,"_84":121,"_77":86,"_98":-5,"_99":-5,"_89":-5},{"_81":95,"_44":123,"_75":-5,"_84":124,"_77":86,"_98":-5,"_99":-5,"_89":-5},{"_81":95,"_44":126,"_75":-5,"_84":127,"_77":86,"_98":-5,"_99":-5,"_89":-5},{"_81":95,"_44":129,"_75":-5,"_84":130,"_77":86,"_98":-5,"_99":-5,"_89":-5},{"_81":95,"_44":132,"_75":-5,"_84":133,"_77":86,"_98":-5,"_99":-5,"_89":-5},{"_81":82,"_44":135,"_75":-5,"_84":136,"_77":86,"_98":-5,"_99":-5,"_89":-5},{"_81":95,"_44":139,"_75":-5,"_84":140,"_77":86,"_98":-5,"_99":-5,"_89":-5},{"_81":95,"_44":142,"_75":-5,"_84":143,"_77":86,"_98":-5,"_99":-5,"_89":-5},{"_81":82,"_44":145,"_75":-5,"_84":146,"_77":86,"_98":-5,"_99":-5,"_89":-5},{"_81":95,"_44":149,"_75":-5,"_84":150,"_77":86,"_98":-5,"_99":-5,"_89":-5},{"_81":95,"_44":152,"_75":-5,"_84":153,"_77":86,"_98":-5,"_99":-5,"_89":-5},{"_81":155,"_44":156,"_75":-5,"_84":157,"_77":86,"_98":-5,"_99":-5,"_89":-5},{"_81":155,"_44":159,"_75":-5,"_84":160,"_77":86,"_98":-5,"_99":-5,"_89":-5},{"_81":155,"_44":162,"_75":-5,"_84":163,"_77":86,"_98":-5,"_99":-5,"_89":-5},{"_81":95,"_44":110,"_75":-5,"_84":165,"_77":86,"_98":-5,"_99":-5,"_89":-5},{"_81":82,"_44":167,"_75":-5,"_84":168,"_77":86,"_98":-5,"_99":-5,"_89":-5},"publicChapterContent","nextChapter","sections",[204,205],"routes/_store+/_layout","routes/_store+/_readers+/_layout","actionData","errors"]