Der Weg zur richtigen Software-Architektur kann manchmal lang sein. Oder sogar sehr lang. Insbesondere, wenn man nicht gerade hauptberuflich Software-Architekt ist und dabei quasi jeden Tag bei seinen Kunden die Entwicklung komplexer Software betreibt.
...
Meine neuesten "Errungenschaften" beeinflussen - mal wieder - mein bisheriges technisches Gesamtbild der Oregami-Web-Anwendung. Im Sommer befasste ich mich endlich mal mit dem Thema "Domain Driven Design" (DDD), welches in Wikipedia beschrieben wird als "eine Herangehensweise an die Modellierung komplexer objektorientierter Software. Die Modellierung der Software wird dabei maßgeblich von den umzusetzenden Fachlichkeiten der Anwendungsdomäne beeinflusst." Bei dieser groben Umschreibung mag man sich vielleicht denken "Ja und?", aber beim Lesen des Buchs "Implementing Domain Driven Design" kamen mir gleich mehrere Erleuchtungen. Viele der dort behandelten Aspekte passen wie die Faust auf's Auge zu Problematiken, die mich bei der Entwicklung für Oregami bisher viel beschäftigt haben. Es geht sogar so weit, dass ich - bevor ich das Buch oder DDD überhaupt kannte - mir bereits selbst ähnliche Lösungsansätze überlegt hatte. Natürlich nur in Ansätzen, aber wenn man dann in so einem Buch liest, wie etwas "richtig" gemacht werden sollte, und seine eigenen Gedanken wieder erkennt, ist das schonmal nicht verkehrt.
Worum geht es nun konkret beim Domain Driven Design? Ich versuche mal, die für mich entscheidenden Punkte zusammenzufassen:
(Man möge mir den Mischmasch aus deutschen und englischen Begriffen verzeihen.)
- Domänen-Experten arbeiten sehr eng mit den Entwicklern zusammen, um in einer gemeinsamen Sprache die Fachlichkeiten zu beschreiben.
- Man erstellt gerade nicht ein gemeinsames, alles umfassendes Modell für sämtliche Fachlichkeiten der Anwendung, sondern man unterteilt die Fachlichkeit nach bestimmten Regeln in mehrere Teilmodelle ("Sub-Domains", "Bounded Contexts").
- Man unterscheidet zwischen "echten Entitäten" und "Value objects". Man verwendet möglichst an vielen Stellen die einfacher zu beherrschenden "Value objects" anstelle von Entitäten, das schafft viele technische Vorteile.
- Innerhalb eines Teilmodells gibt es nur genau ein Entität-Netzwerk ("Aggregate") mit einer Haupt-Entität, auch "Aggregate Root" genannt. Jede Transaktion, die Daten ändert, muss sich immer auf genau so ein Entität-Netzwerk beziehen. Es dürfen nicht mehrere Netzwerke in einer Transaktion angelegt oder geändert werden.
- Beziehungen zwischen zwei Teilmodellen dürfen nur die Haupt-Entität des jeweils anderen Aggregates referenzieren. Diese Haupt-Entität ist auch verantwortlich für alle Regeln (oft wird hier von Invarianten gesprochen), die das Teilmodell betreffen. Es darf keine Regeln geben, die über mehrere Teilmodelle hinweg gelten.
Bei weiteren Recherchen stieß ich auf die sog. "Hexagonale Software-Architektur". Alistair Cockburn schreibt darüber diesen zentralen Satz, der perfekt beschreibt, was man mit so einer Architektur erreichen möchte: "Sorge dafür, dass die Anwendung für menschliche Benutzer, Programme, automatisierte Tests und Batch-Skripte gleichermaßen gut benutzbar ist, und dass sie völlig isoliert von irgendwelchen Laufzeit-Einrichtungen und -Datenbanken entwickelt und getestet werden kann." (Übersetzung des Autors) Wow. Genauso sollte Software sein - universell einsetzbar, gut erweiterbar und gut testbar. Auch unter den Namen "Ports and Adapters" oder "Onion Architecture" wird beschrieben, wie ausgehend vom zentralen Programmcode für die eigentliche Dömane ("innen im Modell") über eine Service-Schicht hinüber zur Infrastruktur-Schicht keinerlei Abhängigkeiten von innen nach außen bestehen. Dadurch bleibt der zentrale Code völlig unabhängig von der Infrastruktur, wodurch man zum einen viel besser testen (Infrastruktur ist über "Ports" austauschbar, für Tests z.B. "in memory") und zum anderen Schnittstellen nach außen für "Clients" (also Software, die auf unsere Domäne zugreift) flexibel über sog. Adapter hinzufügen kann (z.B. ein Zugriff über "ReST", einer über Queues usw.).
...