Themen

Motivation und Begriffsklärung

Aspekte von Software-Architektur

Symptome schlechter und Prinzipien guter Software-Architektur

Im Zentrum: ein Modell der komplexen Realität

Glossar

PDF

Kapitel bei Springer

https://link.springer.com/chapter/10.1007/978-3-662-71607-6_22

• Software ist mehr als die Summe der Einzelteile.
  Ihr wechselweises Zusammenspiel ist entscheidend.
• Softwarearchitektur schlägt die Brücke vom sauberen Code
  einzelner Module zur eigentlichen Anwendung.
• Intuitive Lösungen widersprechen oft dem großen Ziel
  flexibler, erweiterbarer und wiederverwendbarer Software.
• Gute Architektur fokussiert auf die Funktionalität,
  nicht auf konkrete Umsetzungen.
• Ein gutes (abstraktes) Modell des Problemraums
  bildet den Kern einer guten Softwarearchitektur.

Software ist mehr als die Summe ihrer Einzelteile. Entscheidend ist das Zusammenspiel der einzelnen Komponenten. Softwarearchitektur ist die Gestalt eines Systems, die ihm von seinen Entwicklern gegeben wird. Darunter fällt die Aufteilung in einzelne Komponenten, deren Anordnung und Interaktion untereinander. Entscheidend ist hier: Diese Architektur wurde dem System von denen gegeben, die es entwickeln. Architektur wird in den seltensten Fällen von außen aufgezwungen. Das Problem ist meist, dass das Bewusstsein dafür fehlt, dass *jedes* System eine Architektur hat und diese Architektur wesentlich für die Qualität der Software ist. Qualität bemisst sich allgemein an den drei Kriterien Flexibilität, Wiederverwendbarkeit und Wartbarkeit. Auf Architekturebene wird die (fehlende) Qualität oftmals erst nach einer gewissen Zeit deutlich, in der akademischen Welt typischerweise, nachdem die ursprünglichen Autorinnen und Autoren weitergezogen sind. In Kombination mit dem fehlenden Bewusstsein für die Bedeutung von Software- und Systemarchitektur und der mangelnden Wertschätzung der Beschäftigung mit diesen Aspekten ist das ein Hauptgrund für die oft katastrophale Qualität wissenschaftlicher Software und damit in letzter Konsequenz mangelnder Wissenschaftlichkeit, weil die Nachvollziehbarkeit nicht (mehr) gegeben ist.

Es gibt eine Reihe von Hinweisen auf Probleme mit der Softwarearchitektur, auch als architectural smells bezeichnet. Während das Auftreten dieser Symptome vollkommen normal ist, ist der entscheidende und oft vernachlässigte Aspekt das aktive Gegensteuern. Fünf Grundprinzipien der Softwarearchitektur auf relativ niedrigem Abstraktionsniveau, unter dem Akronym SOLID zusammengefasst, werden nachfolgend einzeln behandelt.

Eine entscheidende Voraussetzung für eine erfolgreiche Architektur eines Gesamtsystems ist ein mentales Modell der komplexen Realität, das schriftlich ausformuliert ist und dessen Umsetzung sich im realen Quellcode widerspiegelt. Dieser als Domain Driven Design bezeichnete Ansatz setzt ein tiefes Verständnis der Problemstellung voraus, das nur im Wechselspiel zwischen Problem- und Lösungsdomäne entstehen kann. Im Normalfall der Softwareentwicklung in den Wissenschaften mit Einzelpersonen statt Teams setzt das tiefe Kenntnisse in beiden Bereichen – wissenschaftliche Fachdomäne und Softwareentwicklung – voraus.

Diese Fragen dienen der persönlichen Beschäftigung mit der Thematik, es werden aber keine Antworten zur Verfügung gestellt.

• Welche Ziele verfolgt Softwarearchitektur, wie die gesamte Software-Entwicklung?
• Warum ist gute Softwarearchitektur auch (und gerade) im naturwissenschaftlichen Kontext wichtig?
• Welches Grundprinzip ermöglicht in seinen verschiedenen Ausprägungen flexible, wiederverwendbare und wartbare Software?
• Nennen Sie Vorteile einer Unterteilung des Gesamtprogramms in (möglichst unabhängige) Schichten.
• Welche gängigen Symptome deuten auf eine nicht ausreichende Qualität der Softwarearchitektur hin?
• Was ist der Kerngedanke des Domain-Driven Design?
• Welche Fähigkeiten benötigen Sie, um ein gutes (tragfähiges) Modell für eine Anwendung zu entwickeln?
• Wie ließe sich der Gedanke des Domain-Driven Design auf die wissenschaftliche Datenauswertung anwenden? Wie könnte ein Modell grob aussehen? Welche Komponenten erwarten Sie und welche Grundvoraussetzungen muss das Modell erfüllen?

Zum Domain Driven Design gibt es drei Episoden im SoftwareArchitekTOUR-Podcast auf heise.de:

• https://www.heise.de/developer/artikel/Episode-59-Domain-driven-Design-DDD-4300844.html
• https://www.heise.de/developer/artikel/Episode-61-Domain-Driven-Design-DDD-Episode-2-4366106.html
• https://www.heise.de/developer/artikel/Episode-64-Domain-Driven-Design-DDD-Episode-3-4491758.html

Außerdem gibt es ein Interview mit Alberto Brandolini, dem Erfinder des EventStorming, das den Prozess der Entwicklung eines gemeinsamen Verständnisses der Fragestellung erleichtert.

Weitere Artikel zum Thema Domain Driven Design:

• https://www.heise.de/hintergrund/Grosse-Systeme-mit-Domain-driven-Design-entwerfen-4684074.html
• https://www.heise.de/hintergrund/Domain-driven-Design-und-Bounded-Context-Eigentlich-ganz-einfach-oder-4634258.html

Eine kommentierte und handverlesene Liste mit weiterführender Literatur zum Thema. Die Auswahl ist zwangsläufig subjektiv.

Eine gute Einführung in die grundlegende Architektur von Unternehmensanwendungen (Enterprise Applications) und vor allem die diversen Entscheidungen, die anstehen, liefert der erste Teil (Kapitel 1–8) von [Fowler, 2003Fowler, Martin (2003): Patterns of Enterprise Application Architecture, Addison Wesley, Boston]. Der Rest des Buches ist eine Beschreibung der zugehörigen Muster. Fowler hat einen deutlich nüchterneren Schreibstil als Robert C. Martin (alias „Uncle Bob“), verweist dafür aber deutlich mehr auf die Literatur.

Recht neu und eine Zusammenfassung von vorher in diversen anderen Büchern und Blog-Einträgen verstreuten Informationen ist [Martin, 2018Martin, Robert C. (2018): Clean Architecture. A Craftman's Guide to Software Structure and Design, Prentice Hall, Boston]. Ähnlich schon wie sein Buch „Clean Code“ [Martin, 2008Martin, Robert C. (2008): Clean Code. A Handbook of Agile Software Craftmanship, Prentice Hall, Upper Saddle River, New Jersey] gibt Robert C. Martin hier viele allgemeine Hinweise, wie man gute Software schreibt. Einige Inhalte sind aber auch nur mit minimalen Änderungen aus vorangegangenen Büchern von ihm, u.a. [Martin, 2003Martin, Robert C. (2003): Agile Software Development. Principles, Patterns, and Practices, Prentice Hall, Upper Saddle River, New Jersey, Martin, 2008Martin, Robert C. (2008): Clean Code. A Handbook of Agile Software Craftmanship, Prentice Hall, Upper Saddle River, New Jersey], übernommen.

Der Schwerpunkt der Softwareentwicklung liegt auf der Lösung eines konkreten, komplexen Problems. Entsprechend sollte ein gutes Modell der Problemdomäne den Kern der entwickelten Software bilden. Das ist die Kernaussage des Buches „Domain-Driven Design“ von Eric Evans [Evans, 2004Evans, Eric (2004): Domain-Driven Design, Addison Wesley, Boston]. Die Betonung auf der Bedeutung der Modell-Schicht in einer geschichteten Architektur und ihrer Unabhängigkeit von allen anderen Schichten hat er mit anderen Autoren, allen voran Robert C. Martin [Martin, 2018Martin, Robert C. (2018): Clean Architecture. A Craftman's Guide to Software Structure and Design, Prentice Hall, Boston], gemeinsam. Allerdings liefert er als einer der wenigen sehr detaillierte Hinweise, wie sich ein solches Modell der Problemdomäne entwickeln lässt und worauf man dabei unbedingt achten sollte.

Ein Klassiker, der die Entwicklung objektorientierter Software beschreibt, allerdings (leider) nur noch antiquarisch erhältlich ist, ist Bertrand Meyers „Object-oriented Software Construction“ [Meyer, 1997Meyer, Bertrand (1997): Object-Oriented Software Construction, Prentice Hall PTR, Upper Saddle River, New Jersey]. Das Buch beschreibt dabei alle Ebenen der Softwareentwicklung von den Details des Entwurfs einzelner Klassen bis hin zum abstrakten Zusammenspiel von Komponenten.

Eine gute Zusammenfassung der wesentlichen Kriterien für den Entwurf objektorientierter Software liefern die einführenden Kapitel im Buch der „Viererbande“ [Gamma, 1995Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlissides, John (1995): Design Patterns. Elements of Reusable Object-Oriented Software, Addison-Wesley, Boston], wenngleich in sehr kondensierter Form.

Weitere gute Hinweise zu Softwarearchitektur finden sich auch in Kapitel 3.5 in [McConnell, 2004McConnell, Steve (2004): Code Complete. A practical handbook of software construction, Microsoft Press, Redmond, Washington], Kapitel 5 in [Hunt, 1999Hunt, Andrew; Thomas, David (1999): The Pragmatic Programmer, Addison-Wesley, Boston] und Kapitel 7–12 in [Martin, 2003Martin, Robert C. (2003): Agile Software Development. Principles, Patterns, and Practices, Prentice Hall, Upper Saddle River, New Jersey].

• Evans, Eric (2004): Domain-Driven Design, Addison Wesley, Boston
• Fowler, Martin (2003): Patterns of Enterprise Application Architecture, Addison Wesley, Boston
• Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlissides, John (1995): Design Patterns. Elements of Reusable Object-Oriented Software, Addison-Wesley, Boston
• Hunt, Andrew; Thomas, David (1999): The Pragmatic Programmer, Addison-Wesley, Boston
• Martin, Robert C. (2003): Agile Software Development. Principles, Patterns, and Practices, Prentice Hall, Upper Saddle River, New Jersey
• Martin, Robert C. (2008): Clean Code. A Handbook of Agile Software Craftmanship, Prentice Hall, Upper Saddle River, New Jersey
• Martin, Robert C. (2018): Clean Architecture. A Craftman's Guide to Software Structure and Design, Prentice Hall, Boston
• McConnell, Steve (2004): Code Complete. A practical handbook of software construction, Microsoft Press, Redmond, Washington
• Meyer, Bertrand (1997): Object-Oriented Software Construction, Prentice Hall PTR, Upper Saddle River, New Jersey