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, 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].