Clean Architecture

Das Praxis-Handbuch für professionelles Softwaredesign.Regeln und Paradigmen für effiziente Softwarestrukturierung.

Robert C. Martin

• Verlag: MITP Verlag
• Jahr: 2018
• Thema: Informatik
• ISBN drucken:
  9783958457249
• Thema: Wissenschaft Allgemein
• eBook-ISBN:
  9783958457263

• Praktische Lösungen für den Aufbau von Softwarearchitekturen von dem legendären Softwareentwickler Robert C. Martin (»Uncle Bob«)
• Allgemeingültige Regeln für die Verbesserung der Produktivität in der Softwareentwicklung über den gesamten Lebenszyklus
• Wie Softwareentwickler wesentliche Prinzipien des Softwaredesigns meistern, warum Softwarearchitekturen häufig scheitern und wie man solche Fehlschläge verhindern kann

Wirklich gute Software zu entwickeln, ist ein schwieriges Unterfangen und eine große Herausforderung. Aber wenn Software in der richtigen Art und Weise entwickelt wird, erfordert die Erstellung und Instandhaltung nur wenige Ressourcen, Modifikationen und Anpassungen lassen sich schnell und einfach umsetzen und Mängel und Fehler treten nur hin und wieder in Erscheinung. Der Entwicklungsaufwand ist minimal, und das bei maximaler Funktionalität und Flexibilität.

Was hier utopisch klingt, hat Robert C. Martin schon selbst erlebt und weiß deshalb, dass es so funktionieren kann.

Als Entwickler können Sie Ihre Produktivität über die Lebenszeit eines jeden Softwaresystems dramatisch verbessern, indem Sie allgemeingültige Grundsätze für die Entwicklung professioneller Softwarearchitektur anwenden. In diesem Buch verrät Ihnen der legendäre Softwareentwickler diese maßgeblichen Prinzipien und zeigt Ihnen, wie Sie diese erfolgreich und effektiv anwenden.

Basierend auf seiner mehr als 50-jährigen Berufserfahrung mit Softwareumgebungen jeder erdenklichen Art demonstriert Robert C. Martin in diesem Buch auf eindrucksvolle Weise, welche Entscheidungen Sie im Entwicklungsprozess treffen sollten und warum diese für Ihren Erfolg ausschlaggebend sind. Wie man es von »Uncle Bob« kennt, enthält dieses Buch zahlreiche unmittelbar anwendbare und in sich schlüssige Lösungen für die Herausforderungen, mit denen Sie im Berufsleben konfrontiert sein werden – jenen, die über Gedeih und Verderb Ihrer Projekte entscheiden.

In diesem Buch lernen Sie:

• Architektonische Zielsetzungen der Softwareentwicklung richtig abstecken und die dafür notwendigen Kerndisziplinen und -praktiken planvoll einsetzen
• Die grundlegenden Prinzipien des Softwaredesigns für den Umgang mit Funktionalität, Komponententrennung und Datenmanagement meistern
• Den Entwicklungsprozess optimieren durch die zielgerichtete Anwendung von Programmierparadigmen und die klare Definition der Handlungsspielräume der Softwareentwickler
• Wichtige systemrelevante Programmbestandteile von bloßen »Details« unterscheiden
• Optimale, hochschichtige Strukturen für Web, Datenbank, Fat Client, Konsole und eingebettete Anwendungen implementieren
• Angemessene Grenzen und Layer definieren und die Komponenten und Services in Ihrem System organisieren
• Faktoren für das Scheitern von Softwaredesigns und -architekturen erkennen und diese Fehler vermeiden

Clean Architecture ist für jeden gegenwärtigen oder angehenden Softwarearchitekten, Systemanalysten, Systemdesigner und Softwaremanager eine Pflichtlektüre – ebenso wie für jeden Programmierer, der die Softwaredesigns anderer Entwickler ausführen muss.

Kapitel 1:
Was bedeuten »Design« und »Architektur«?‌

Im Laufe der Jahre sorgte die Verwendung der Begriffe »Design‌« und »Architektur‌« immer wieder für Verwirrung. Was ist Design? Was ist Architektur? Und wo liegt der Unterschied?

Eine der Zielsetzungen dieses Buches besteht darin, Ihnen einen Weg durch das verworrene Dickicht der Begriffsauslegungen aufzuzeigen und ein für alle Mal zu definieren, was genau unter Design und Architektur zu verstehen ist. Für den Anfang soll an dieser Stelle zunächst einmal festgehalten werden, dass es eigentlich keinen Unterschied gibt. Überhaupt keinen Unterschied.

Das Wort »Architektur« wird häufig im Zusammenhang mit Dingen auf einer übergeordneten Ebene verwendet, die sich von den Details auf einer untergeordneten Ebene unterscheiden. Mit »Design« scheinen dagegen oftmals Strukturen‌ und Entscheidungen auf einer untergeordneten Ebene bezeichnet zu werden. Betrachtet man die Arbeit eines echten Architekten, ist diese Begriffsverwendung jedoch geradezu absurd.

Versetzen Sie sich doch einmal in den Architekten, der Ihr neues Haus entwirft. Besitzt dieses Gebäude eine Architektur? Natürlich! Und worin besteht diese Architektur? Nun, einerseits beschreibt sie die Gestalt des Hauses – sein äußeres Erscheinungsbild, den Aufriss und die Anordnung des Wohnraums bzw. der Räume. Wenn Sie sich jedoch die Planungsentwürfe Ihres Architekten anschauen, werden Sie darin zum anderen auch eine Vielzahl von untergeordneten Details entdecken. So ist zum Beispiel ausgewiesen, wo jede einzelne Steckdose, jeder einzelne Lichtschalter und jede einzelne Lampe platziert werden wird. Sie können sehen, welche Schalter welche Lampen steuern. Ebenso lässt sich feststellen, wo der Kamin errichtet werden wird und an welchen Standorten und in welcher Größe der Warmwasserboiler und die Schmutzwasserpumpe installiert werden. Und darüber hinaus werden Sie auch detaillierte Darstellungen der Wand-, Dach- und Fundamentkonstruktionen vorfinden.

Kurz: Die Pläne geben Auskunft über alle winzigen Details, die sämtliche auf der übergeordneten Ebene getroffenen Entscheidungen stützen. Und es wird deutlich, dass diese untergeordneten Details und die übergeordneten Entscheidungen Teil des Gesamtentwurfs des Hauses sind.

Genauso verhält es sich auch mit dem Softwaredesign. Die untergeordneten (low-level) Details und die übergeordnete (high-level) Struktur sind allesamt Teil desselben Ganzen. Zusammen bilden sie ein durchgängiges Konstrukt, das die Gestalt des Systems definiert. Das eine kann nicht ohne das andere sein. Tatsächlich gibt es keine eindeutige Grenzlinie zwischen diesen beiden Komponenten – es gibt einfach nur ein Kontinuum an Entscheidungen, die sich von der höchsten bis zu den niedrigsten Ebenen erstrecken.

1.1 Das Ziel‌?

Und die Zielsetzung dieser Entscheidungen? Das Erreichen eines guten Softwaredesigns? Dieses Ziel entspricht nichts Geringerem als meiner »utopischen« Beschreibung:

Das Ziel der Softwarearchitektur besteht in der Minimierung der menschlichen Ressourcen, die für das Errichten und die Instandhaltung des benötigten Systems erforderlich sind.

Die Qualität des Designs‌ bemisst sich schlicht und ergreifend an dem Ausmaß des Aufwands, der erforderlich ist, um den Bedürfnissen der Kunden gerecht zu werden. Bedarf es hierfür eines geringen Aufwands und bleibt dies auch während der gesamten Lebenszeit des Systems so, dann handelt es sich um ein gutes Design – steigt der Aufwand mit jedem neuen Release, taugt das Design nichts. So einfach ist das.

1.2 Fallstudie

Die nachstehende Fallstudie soll hier als Beispiel dienen. Sie weist reale Daten eines echten Unternehmens aus, das jedoch anonym bleiben möchte.

Werfen wir zunächst einen Blick auf den Anstieg des technischen Mitarbeiterstabs im Engineering-Bereich. Sicher werden Sie zustimmen, dass dieser Trend äußerst vielversprechend aussieht. Das in Abbildung 1.1 gezeigte Personalwachstum muss doch ein Indikator für einen bedeutenden Erfolg sein!

Abb. 1.1: Personalwachstum im Engineering-Bereich (Abdruck mit freundlicher Genehmigung von Jason Gorman)

Betrachten wir als Nächstes die Produktivität‌ des Unternehmens in demselben Zeitraum, und zwar gemessen an den Lines of Code‌‌, also der Anzahl der Codezeilen‌ (siehe Abbildung 1.2).

Abb. 1.2: Produktivität über denselben Zeitraum hinweg

Hier läuft ganz offenkundig irgendetwas nicht richtig: Obwohl jedes Release unter Zuhilfenahme einer stetig steigenden Anzahl von Entwicklern bearbeitet wird, scheint der Code lediglich in einem asymptotischen Verhältnis dazu anzuwachsen.

Was nun folgt, ist allerdings eine noch weitaus besorgniserregendere Grafik: Abbildung 1.3 zeigt, wie sich die Kosten pro Codezei‌le im Zeitverlauf verändert haben.

Abb. 1.3: Kosten pro Codezeile im Zeitverlauf

Diese Trendentwicklungen sind definitiv nicht tragbar. Egal, wie profitabel das Unternehmen zum gegenwärtigen Zeitpunkt auch dastehen mag: Verlaufskurven wie diese werden die Gewinne des Geschäftsmodells in katastrophaler Art und Weise belasten und die Firma in die Verlustzone treiben – wenn nicht sogar direkt in die Pleite.

Doch was in aller Welt hat diese bemerkenswerte Veränderung in Bezug auf die Produktivität verursacht? Warum war die Codeerstellung für Release Nummer 8 gleich 40 Mal teurer als für Release Nummer 1?

1.2.1 Die Signatur des Chaos‌‌

Was Sie in den vorstehenden Grafiken gesehen haben, könnte man auch als die »Signatur des Chaos‌‌« bezeichnen. Wenn Systeme hastig zusammengeschustert werden, wenn die schiere Anzahl der Programmierer der alleinige Antrieb für den zu erzielenden Output ist und wenn nur wenige bis gar keine Überlegungen hinsichtlich der Sauberkeit des Codes oder der Struktur des Designs angestellt werden, dann können Sie gewiss sein, dass Sie den hier demonstrierten eingeschlagenen Weg bis zum bitteren Ende gehen werden.

In Abbildung 1.4 ist zu sehen, wie sich dieser Weg für die Entwickler darstellt: Sie haben mit einer Produktivität von nahezu 100 % angefangen, die dann jedoch mit jedem weiteren Release radikal abfiel. Bereits ab Release Nummer 4 wurde deutlich, dass ihre Produktivität in einer asymptotischen Annäherung gegen null abflachen würde.

Abb. 1.4: Produktivität je Release

Aus Sicht der Entwickler ist das enorm frustrierend, weil sie faktisch alle die ganze Zeit über unvermindert hart an dem Programm weitergearbeitet haben – ohne dass auch nur ein einziger von ihnen seine Anstrengungen verringert hätte.

Und doch, trotz all ihres heroischen Einsatzes, der Überstunden und ihrer Hingabe, bringen sie einfach nicht mehr viel zustande. All ihre Bemühungen entfernen sich zusehends von den Features weg und richten sich nun immer mehr darauf, das entstandene Chaos zu verwalten. Ihre Aufgabe hat sich somit inzwischen dahin gehend verändert, dass sie jetzt das Chaos von einer Stelle zur nächsten verlagern, und wieder zur nächsten und übernächsten, damit sie überhaupt noch in der Lage sind, auch nur ein einziges weiteres mickriges Feature zu ergänzen.

1.2.2 Die Perspektive der Unternehmensleitung

Wenn Sie nun glauben, das sei schon übel, dann stellen Sie sich nur einmal vor, wie sich die Sachlage der Führungsebene des Unternehmens darstellt! Abbildung 1.5 zeigt die Entwicklung der monatlichen Gehaltszahlung‌en für denselben Zeitraum.

Release Nummer 1 wurde bei monatlichen Gehaltszahlungen von wenigen Hunderttausend US-Dollar fertiggestellt. Das zweite Release kostete bereits ein paar Hunderttausend Dollar mehr. Und mit Release Nummer 8 hatten die monatlichen Zahlungen bereits 20 Millionen US-Dollar erreicht, Tendenz steigend!

Abb. 1.5: Entwicklung der monatlichen Gehaltszahlungen je Release

Allein dieses Diagramm ist schon erschreckend. Zweifelsohne ist hier irgendetwas Alarmierendes im Busch. Man kann nur hoffen, dass die Erträge die Kosten am Ende übersteigen werden und somit die Ausgaben rechtfertigen – doch egal, wie man diesen Kurvenverlauf auch betrachtet, er gibt in jedem Fall Anlass zur Sorge.

Vergleichen Sie die Kurve in Abbildung 1.5 nun aber mal mit den pro Release geschriebenen Codezeilen in Abbildung 1.2. Mit der Investition von ursprünglich wenigen Hunderttausend Dollar pro Monat wurde eine Menge Funktionalität erzielt – die letzten 20 Millionen Dollar brachten dagegen nahezu nichts! Jeder CFO bzw. Finanzdirektor wird mit einem Blick auf diese beiden grafischen Darstellungen erkennen, dass sofort etwas unternommen werden muss, um die bevorstehende Katastrophe abzuwenden.

Doch was lässt sich dagegen unternehmen? Was ist hier schiefgelaufen? Wodurch wurde dieser unglaubliche Produktivitätsabfall verursacht? Was kann die Managementebene anderes tun, als mit den Füßen aufzustampfen und den Entwicklern ihren Unmut kundzutun?

1.2.3 Was ist schiefgelaufen?

Vor fast 2.600 Jahren erzählte der griechische Dichter Äsop die Fabel von der Schildkröte und dem Hasen. Die Moral dieser Geschichte wurde im Laufe der Zeit auf vielerlei unterschiedliche Weise interpretiert:

• »Eile mit Weile.«
• »Nicht den Schnellen gehört im Wettlauf der Sieg, nicht den Tapferen der Sieg im Kampf.«
• »Blinder Eifer schadet nur.«

Im Prinzip illustriert diese Fabel die Unvernunft der Selbstüberschätzung‌‌‌: Der Hase vertraut dermaßen auf die ihm eigene Schnelligkeit, dass er das Rennen nicht ernst genug nimmt und ein Nickerchen hält, während die Schildkröte unterdessen die Ziellinie überquert.

Moderne Entwickler finden sich in einer ähnlichen Wettbewerbssituation wieder – und stellen eine ganz ähnliche Selbstüberschätzung zur Schau. Allerdings schlafen sie nicht, ganz im Gegenteil: Die Programmierer von heute arbeiten buchstäblich Tag und Nacht. Dennoch: Ein Teil ihres Verstandes befindet sich oftmals tatsächlich im Dämmerschlaf – und zwar der Teil, der im Grunde genommen genau weiß, dass guter, sauberer und ordentlich designter Code den entscheidenden Unterschied macht.

Diese Entwickler erliegen einer landläufigen Illusion: »Aufräumen können wir später immer noch, jetzt müssen wir das System aber zuerst mal auf den Markt bringen!« Allerdings wird der Code im Nachhinein natürlich nicht mehr aufgeräumt – ganz einfach weil der Marktdruck niemals nachlässt. Ist die Markteinführung erst einmal vollzogen, hat man sofort eine Horde von Wettbewerbern auf den Fersen, denen man um jeden Preis vorausbleiben muss, indem man im übertragenen Sinne so schnell rennt, wie man nur kann.

Dementsprechend wird den Programmierern zu keinem Zeitpunkt ein Wechsel ihres Arbeitsmodus gelingen. Sie können nicht zurück und den vorhandenen Code säubern, weil sie schon gleich wieder das nächste Feature fertigstellen müssen – und das nächste und das nächste und das nächste. So häuft sich immer mehr Unordnung an, und in der Konsequenz nimmt die Produktivität einen zielstrebigen asymptotischen Verlauf gegen null.

Ebenso wie der Hase der Selbstüberschätzung seiner Schnelligkeit erlag, verfallen auch die Entwickler einer Selbstüberschätzung in Bezug auf ihre Fähigkeit, produktiv zu bleiben. Das Chaos, das sich in den Code einschleicht und ihre Produktivität beeinträchtigt, setzt sich somit unerbittlich fort. Und wenn diesem Prozess nicht Einhalt geboten wird, reduziert er ebendiese Produktivität binnen weniger Monate auf null.

Ein noch gravierenderer Trugschluss, dem die Entwickler erliegen, ist jedoch die Vorstellung, dass ihnen das Schreiben von unordentlichem Code kurzfristig einen Geschwindigkeitsvorteil bringen und alles andere auf lange Sicht nur aufhalten würde. Programmierer, die diesem Irrglauben aufsitzen, demonstrieren nicht nur die Selbstüberschätzung des Hasen in Bezug auf ihre Fähigkeit, den Wechsel vom chaotischen Arbeiten zur zukünftigen Beseitigung der angerichteten Unordnung zu vollziehen, sondern begehen darüber hinaus auch einen simplen faktischen Fehler, denn: Tatsache ist, dass Unordnung immer für mehr Verzögerungen sorgt als die fortgesetzte Einhaltung sauberer Programmierung, unabhängig davon, welcher Zeitrahmen zugrunde gelegt wird.

Betrachten Sie in diesem Zusammenhang einmal die Ergebnisse eines bemerkenswerten, von Jason Gorman unternommenen Experiments, das in Abbildung 1.6 veranschaulicht ist. Jason führte seine Untersuchungsreihe über einen Zeitraum von sechs Tagen durch. An je...

Inhaltsverzeichnis

• Impressum
• Vorwort
• Einleitung
• Über den Autor
• Danksagung
• Teil I: Einführung
• Kapitel 1: Was bedeuten »Design« und »Architektur«?‌
• Kapitel 2: Die Geschichte zweier Werte‌
• Teil II: Die ersten Bausteine setzen: Programmierparadigmen‌‌
• Kapitel 3: Die Paradigmen‌
• Kapitel 4: Strukturierte Programmierung‌
• Kapitel 5: Objektorientierte Programmierung‌
• Kapitel 6: Funktionale Programmierung‌
• Teil III: Designprinzipien‌
• Kapitel 7: SRP: Das Single-Responsibility-Prinzip‌
• Kapitel 8: OCP: Das Open-Closed-Prinzip‌
• Kapitel 9: LSP: Das Liskov’sche Substitutionsprinzip‌
• Kapitel 10: ISP: Das Interface-Segregation-Prinzip‌
• Kapitel 11: DIP: Das Dependency-Inversion-Prinzip‌
• Teil IV: Komponentenprinzipien‌
• Kapitel 12: Komponenten‌
• Kapitel 13: Komponentenkohäsion‌
• Kapitel 14: Komponentenkopplung‌‌‌
• Teil V: Softwarearchitektur
• Kapitel 15: Was ist Softwarearchitektur?
• Kapitel 16: Unabhängigkeit‌‌
• Kapitel 17: Grenzen‌: Linien ziehen
• Kapitel 18: Anatomie der Grenzen‌
• Kapitel 19: Richtlinien‌ und Ebenen‌
• Kapitel 20: Geschäftsregeln‌
• Kapitel 21: Die schreiende Softwarearchitektur‌
• Kapitel 22: Die saubere Architektur‌
• Kapitel 23: Presenters und »Humble Objects«‌‌
• Kapitel 24: Partielle Grenzen‌‌
• Kapitel 25: Layer und Grenzen‌
• Kapitel 26: Die Komponente Main‌
• Kapitel 27: Services‌ – große und kleine
• Kapitel 28: Die Testgrenze‌
• Kapitel 29: Saubere eingebettete Architektur‌
• Teil VI: Details
• Kapitel 30: Die Datenbank ist ein Detail‌‌‌
• Kapitel 31: Das Web ist ein Detail‌‌‌
• Kapitel 32: Ein Framework ist ein Detail‌‌‌
• Kapitel 33: Fallstudie: Software‌ für den Verkauf von Videos
• Kapitel 34: Das fehlende Kapitel‌
• Anhang A: Architekturarchäologie
• Anhang B: Nachwort