Robert C. Martin: Clean Architecture

You are currently viewing Robert C. Martin: Clean Architecture

Robert C. Martin
Mit Beiträgen von: James Grenning, Simon Brown
Vorwort von: Kevlin Henney
Nachwort von: Jason Gorman
Übersetzung: Maren Feilen, Knut Lorenzen
Clean Architecture: Das Praxis-Handbuch für professionelles Softwaredesign. Regeln und Paradigmen für effiziente Softwarestrukturen.

1. Auflage
2018, 373 Seiten, Broschur
mitp-Verlag
ISBN: 978-3-95845-724-9

Informationen zum Buch im Katalog der Deutschen Nationalbibliothek.



Clean Architecture ist ein Buch in dem es in erster Reihe um Prinzipien, um Allgemeines geht. Das Buch ist gut und verdient gelesen zu werden, eine konkretere, praktischere Herangehensweise wäre aber hilfreich gewesen.


Struktur

Robert C. Martins – vielen unter seinem „Markennamen“ Uncle Bob bekannt – drittes Buch aus der sogenannten „Clean-Reihe“ ist in sechs Teilen unterteilt.

Einer kurzen Einleitung (erster Teil) folgt die Beschreibung der drei wichtigsten Programmierparadigmen (strukturiert, objektorientiert und funktional) und – im dritten Teil – die Darlegung der von Martin popularisierten SOLID-Prinzipien. Im vierten Teil geht es um Prinzipien, die für Komponenten gelten (in die Kategorien Kohäsion und Kopplung unterteilt) und im fünften – fast ein Drittel des Buches ausmachenden Teils – um „Softwarearchitektur“. In Teil sechs wird aufgezählt, was alles ein „Detail“ aus Architektursicht darstellt und es wird argumentiert, wieso das der Fall ist.

Das Buch endet mit zwei Anhängen: Anhang A ist eine kurze Geschichte der Softwareentwicklung, die auf Uncle Bobs persönlicher Erfahrung beruht und Anhang B ist ein kurzes Nachwort.

Inhalt

Teil I – Einführung

Im ersten, vergleichsweise kurzen Teil geht es um zwei Unterscheidungen:

  • Design vs. Architektur und
  • Verhalten vs. Struktur.

Die „Design vs. Architektur“-Thematik ist nicht neu, für gewöhnlich wird zwischen den beiden Termini unterschieden auch wenn sehr uneinheitlich. So geht es bei der „Architektur“ eher um die nichtfunktionalen Aspekte und beim „Design“ um das Konkretere. Martin findet diese Unterscheidung jedoch „geradezu absurd“ aus Sicht eines „echten Architekten“ (S. 29), die zwei Begriffe sind somit aus seiner Sicht äquivalent.

Verhalten und Struktur sind zwei wichtige Aspekte – „Werte“, wie sie Martin nennt – einer Software. Verhalten bedeutet „Funktionalität“ und die Struktur entspricht der Architektur. Beides sei wichtig, wobei die Manager das Verhalten favorisieren würden. Damit aber der Implementierungsaufwand neuer Funktionalität nicht aus dem Ruder läuft, muss immer auch die Architektur berücksichtigt werden. Es sei die Verantwortung der Architekten und Entwickler für eine gute Architektur zu „ringen“, da dem Management die Wichtigkeit derselben nicht unbedingt bewusst sei (S. 43).

Weiter geht es im zweiten Teil mit den Programmiersprachen bzw. -paradigmen.

Teil II – Die ersten Bausteine setzten: Programmierparadigmen

Martin interpretiert die drei (wichtigsten) Programmierparadigmen als jeweilige Einschränkung dessen, was er „Programmierfreiheit“ nennt – so wird laut dem Autor

  • durch die strukturierte Programmierung die „direkte Kontrollübertragung“,
  • durch das objektorientierte Programmierparadigma die „indirekte Kontrollübertragung“ und
  • durch die funktionalen Sprachen die „Variablenzuweisung“

eingeschränkt bzw. in seinen Worten „einer strengen Disziplin [unterworfen]“ (S. 79). Dabei stellt Martin fest, dass die grundlegenden Programmierprinzipien schon gelten, seit Code geschrieben wurde.

Teil III – Designprinzipien

Im dritten Teil widmet sich der Autor den fünf von ihm popularisierten SOLID-Prinzipien. Wegen ihrer Popularität sollen diese hier lediglich aufgelistet werden:

  • das Single Responsibility Principle (SRP)
  • das Open-Closed Principle (OCP)
  • das Liskov Substitution Principle (LSP)
  • das Interface Segregation Principle (ISP) und
  • das Dependecy Inversion Principle (DIP).

Teil IV – Komponentenprinzipien

Der vierte Teil fährt mit der Erklärung weiterer Prinzipien fort, nun mit solchen, die auf der höheren Ebene der Komponenten angesiedelt sind. Diese haben zwar nicht die gleiche „Berühmtheit“ wie die SOLID-Prinzipien erfahren, sie dürften aber trotzdem als „Package Principles“ relativ bekannt sein:

  • Prinzipien, welche die Kohäsion von Komponenten betreffen:
    • das Reuse-Release Equivalence Principle (REP)
    • das Common-Closure Principle (CCP)
    • das Common-Reuse Principle (CRP)
  • Prinzipien, welche die Kopplung von Komponenten betreffen:
    • das Acyclic Dependencies Principle (ADP)
    • das Stable-Dependencies Principle (SDP)
    • das Stable-Abstractions Principle (SAP)

Teil V – Softwarearchitektur

Nach etwas über 120 Seiten „Grundlagen“ folgen fast ebenso viele Seiten zum eigentlichen Thema: der Softwarearchitektur. Dabei kommt das in den ersten vier Teilen Geschriebene zur Anwendung.

Zuerst stellt Martin die Frage nach dem Wesen der Softwarearchitektur. Die Softwarearchitektur ist dafür verantwortlich die definierten Anwendungsfälle des Systems umzusetzen, die Wartung, Entwicklung und Weiterentwicklung desselben zu ermöglichen und das Deployment zu unterstützen (vgl. S. 165 ff.).

Es geht im fünften Teil – selbstverständlich – viel um das Thema „Grenzen“, also um Schnittstellen, wo zieht man diese und wie verbirgt man die „Details“ hinter ihnen. Einige konkrete Architekturstile und Muster werden ebenfalls (eher kurz) beschrieben. Den Abschluss dieses Teils macht das Thema Architektur eingebetteter Systemen.

Laut Martin geht es bei einer guten Architektur in erster Linie um maximal mögliche Flexibilität, was in der Maxime kulminiert: „Ein guter Softwarearchitekt maximiert die Anzahl der noch nicht gefällten Entscheidungen.“ (S. 159, auf die kursive Schrift im Original wurde verzichtet). So erklärt sich auch, dass Manches einfach als irrelevantes oder sich potenziell änderndes Detail anzusehen ist bzw. sein sollte. Was alles aus Sicht des Autors als Detail angesehen werden kann, ist Thema des sechsten Teils.

Teil VI – Details

Drei „Details“ von denen eine Architektur unabhängig sein sollte, identifiziert Uncle Bob, Details, die aber oft nicht als solche angesehen werden:

  • Das Datenmodell ist aus Martins Sicht äußerst wichtig für die Architektur, die konkrete Art der Datenhaltung, also die Datenbank, nicht.
  • Das Web sei lediglich eine Art der Darstellung, somit ein irrelevantes Detail aus Architektursicht. Oder auf Martins direkter Art: „Das GUI ist ein Detail. Und das Web ist eine GUI – ergo ist das Web ein Detail.“ (S. 281)
  • Das verwendete Framework ist, oder eher sollte, ein Detail sein. Idealerweise sollte das verwendete Framework nicht die gesamte Struktur einer Software bestimmen.

Anhänge

Clean Architecture endet mit zwei Anhängen, dem ersten, der Architekturarchäologie betitelt ist und einem kurzen Nachwort im zweiten. Architekturarchäologie ist stark autobiographisch geprägt, der Autor erzählt seine Erfahrungen mit Architekturen beginnend mit den 70er und endend mit dem Anfang der 90er Jahren des vorigen Jahrhunderts.

Diskussion

Clean Architecture ist das dritte Buch aus Martins sogenannter – bisher vier Bücher umfassenden – „Clean-Reihe“ und obwohl es etliche Schwächen hat, finde ich es – alles in allem – das Beste der vieren.

Aber eins nach dem anderen. Fangen wir mit den Schwächen an:

  • Clean Architecture ist kein „praktisches“ Buch, es geht mehr um Prinzipien, von denen man sich beim Entwickeln einer Architektur leiten lassen sollte. Wer allzu viel Konkretes oder gar Code erwartet, der sollte zu einem anderen Buch greifen. (Der Fairness halber muss erwähnt werden, dass es tatsächlich auch einige wenige Code-Beispiele gibt.) Prinzipien sind wichtig, die Beschreibung von mehr konkreten Architekturstilen mit Vor- und Nachteilen und deren Einsatzszenarien wäre – vor allem für weniger erfahrene Entwickler – aber hilfreich gewesen.
  • Die ersten vier Teile, also die „Grundlagen“ nehmen vergleichsweise viel Platz ein, oder anders ausgedrückt: nach 120 Seiten Grundlagen erwarte ich wesentlich mehr als 120 Seiten Hauptteil (je nachdem wie man den sechsten Teil einordnet, könnte man argumentieren, dass zusätzliche 40 Seiten zum Hauptteil gehören).
  • Clean Architecture ist ein Buch, das sich an eine breite Leserschaft adressiert. Dass ältere, anderweitig publizierte Ideen im Buch wiederholt werden, ist keineswegs „falsch“, aber es erscheint mir wünschenswert, dass dies begründet bzw. gekennzeichnet ist.
    So sind die SOLID-Prinzipien und die Komponentenprinzipien schon altbekannt und an vielen Stellen zu finden (unter anderem z.B. in Martins älterem Buch Agile Software Development: Principles, Patterns, and Practices). Der Verweis auf das genannte Buch und auch auf andere Stellen, wo die SOLID-Prinzipien zusammengefasst sind, fehlt nicht, es leuchtet mir aber nicht ein, weswegen diese Prinzipien auf etwa 70 Seiten wiederholt werden müssen.
    Mindestens die zwei Kapitel Die schreiende Softwarearchitektur und Die saubere Architektur beruhen auf die gleichnamigen Blogposts Martins (Screaming Architecture und The Clean Architecture), worauf sich, soweit ich das feststellen kann, keine Referenz findet, was mir aber sinnvoll erschiene.

Und nun zur großen Frage: Wieso finde ich das Buch trotzdem so gut? Nun „so gut“ vielleicht doch nicht, aber aus etlichen Gründen besser als die anderen drei Bücher der Reihe.

Hier sind die Gründe:

  • Der erste Teil von Clean Code ist zwar sehr gut, das Buch als Ganzes leidet aber stark in meinen Augen wegen des viel zu vielen abgedruckten Codes. Clean Architecture ist wahrscheinlich für den einzelnen Entwickler nicht so hilfreich wie Clean Code, das Niveau des Buches ist aber ausgeglichen und somit als Ganzes besser. Dass Clean Code „hilfreicher“ sein könnte, hängt auch damit zusammen, dass Empfehlungen und Vorschriften auf Code-Ebene vergleichsweise einfacher sind als auf Architekturebene.
  • Clean Coder vermischt meines Erachtens viel zu stark das Autobiographische mit den Kernaussagen des Buches. Zwar fehlen auch in Clean Architecture die autobiographischen Informationen nicht, sie sind aber im Anhang A gebündelt, was ebenfalls zur Einheitlichkeit und Ausgeglichenheit des Textes führt.
  • Martin hat einen direkten Ausdrucksstil, der für meinen Geschmack ab und zu doch zu direkt ist und zu oft zu stark ins Normative und Präskriptive ausrutscht. Dieser Stil ist aber auch das, was seine Bücher so leicht lesbar macht. In Clean Coder fand ich den Stil besonders störend, in Clean Agile ebenfalls, jedoch in einem geringeren Maße. Clean Architecture bleibt von der Direktheit des Stils nicht verschont, ich kann mich aber an keiner Stelle erinnern, die für mich störend gewesen wäre.

Clean Architecture ist ein Buch in dem es in erster Reihe um Prinzipien, um Allgemeines geht. Das kommt nicht von Ungefähr. Das „Axiom“ von dem Martin ausgeht, ist, dass die Regeln der Architektur einen absoluten Charakter hätten (vgl. S. 19 f.). So betrachtet, macht es durchaus Sinn, den Akzent auf Prinzipien und allgemeine Regeln zu setzten statt auf konkrete Architekturstile und -muster. Das Buch ist gut und verdient gelesen zu werden, wenn man aber an Softwarearchitektur interessiert ist, wird man nicht drumherum kommen auch weitere Bücher zu lesen, die eine konkretere Herangehensweise haben.


Zum Autor

Informationen über Robert C. Martin finden Sie hier.


Folgende Rezensionen könnten Sie ebenfalls interessieren:

Petre Sora

Petre Soras Interessen sind vielfältig und befinden sich an der Schnittstelle zwischen Mensch und Informationstechnologie. Als studierter Psychologe und Software Engineer war er sechs Jahre als Java-Entwickler in mehreren Unternehmen tätig. Mit der Gründung der Rezensionsplattform nososo hat er sich entschieden eigene Wege zu gehen.

Schreibe einen Kommentar