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.
Zum Domain Driven Design gibt es drei Episoden im SoftwareArchitekTOUR-Podcast auf heise.de:
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:
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-m-2003]}. 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-rc-2018]}. Ähnlich schon wie sein Buch „Clean Code“ {[martin-rc-2008]} 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-rc-2003,martin-rc-2008]}, ü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-e-2004]}. 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-rc-2018]}, 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-b-1997]}. 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-e-1995]}, wenngleich in sehr kondensierter Form.
Weitere gute Hinweise zu Softwarearchitektur finden sich auch in Kapitel 3.5 in {[mcconnell-s-2004]}, Kapitel 5 in {[hunt-a-1999]} und Kapitel 7–12 in {[martin-rc-2003]}.
<bibtex bibliography> sort=true </bibtex>