Mich fragte heute jemand etwas zu Software-Design und wie man etwas im Domänen-Modell am besten umsetzt. Das brachte mich wieder dazu, dass ich immer Schwierigkeiten habe das Fachdomänen-Modell-Konzept, gerade in Bezug auf Domain-Driven-Design, zu erklären. Beim Duschen (warum eigentlich immer da?) kam mir da ein Gedanke:
Die Definition von Modell
Die Definition von Modell, allgemein und auch in der Informationstechnik, lautet:
Ein Modell ist ein beschränktes Abbild der Wirklichkeit.
Daher kommen auch die wunderbaren OO-Erklärungen mit Autos, die aus Reifen, Lenkrädern etc. bestehen.
Das Problem
Diese Erklärungen hinken immer, zumindest in der Informationstechnik. Z.B. würde ja niemand, um eine Auto-Fahrsimulation zu schreiben, ein Auto aus all den realen Objekten zusammensetzen und diese dann interagieren lassen, nur um nach rechts und links lenken zu können.
Genauere Definitionen
Wenn man die Modell-Definition in Wikipedia mal weiter durch geht, kann man das “Hinken” komplett auflösen.
1. Abbildung – Ein Modell ist stets ein Modell von etwas, nämlich Abbildung, Repräsentation eines natürlichen oder eines künstlichen Originals, das selbst wieder Modell sein kann.
Ok, das beschreibt es genauer. Das hilft uns hier nicht.
2. Verkürzung – Ein Modell erfasst im Allgemeinen nicht alle Attribute des Originals, sondern nur diejenigen, die dem Modellschaffer bzw. Modellnutzer relevant erscheinen.
Das hilft mehr, wobei “beschränkt” ja schon genannt wurde. Für die Fahrsimulation brauche ich also keine Reifen, sondern nur ein Lenkrad, Gas und Bremse. Das ist jetzt aber auch noch nicht sonderlich erleuchtend. Der “Modellnutzer” kommt schon vor … das wird gleich konkreter.
Der gewisse Unterschied
Wirklich bringen tut’s der letzte Teil:
3. Pragmatismus – Modelle sind ihren Originalen nicht per se eindeutig zugeordnet. Sie erfüllen ihre Ersetzungsfunktion a) für bestimmte Subjekte (Für Wen?), b) innerhalb bestimmter Zeitintervalle (Wann?) und c) unter Einschränkung auf bestimmte gedankliche oder tätliche Operationen (Wozu?).
Ich erstelle ein Modell immer für einen Anwender und einen Anwendungszweck. Der letzte Teil und das explizite UND wird gerne vergessen.
D.h. mein ominöses Auto, auch wenn es nur eine Entität ist, sollte in einer Anwendung mehrere Modelle besitzen, wenn es mehrere Akteure und/oder Anwendungsfälle gibt und es dort nötig und sinnvoll erscheint.
Ein abstraktes Beispiel (das Auto, was sonst)
Der Fahrer braucht zum Fahren nur Gas, Bremse, rechts lenken, links lenken … etc. Da kommt “Rad”, “Getriebe”, “Auspuff” nicht vor.
Der Mechaniker braucht zum Reparieren Rad, Radmuttern, Bremsschlauch … etc. Er muss aber nie nach rechts lenken.
Will man all das in einem einzigen Modell bzw. eben einer Klasse unterbringen, wird schon mal recht voll.
Wenn aber der Mechaniker das Auto auch testen will, muss er auch lenken, Gas geben etc. Aber das hat andere Auswirkungen als beim Fahren.
Das jetzt in einer Klasse wird wirklich übel. Vererbung, um das Verhalten zu ändern, ist da der falsche Ansatz (wer soll da von wem erben… und warum?).
Verständlicher, aufgeräumter und meiner Meinung nach Sinniger ist es da, für jeden dieser Fälle ein eigenes Fachdomänen-Modell zu haben. Physisch kann alles auf einer Entität basieren, Z.B. genau ein Datenbankeintrag sein. Und es ist im Sinne von DDD: es gibt nicht nur das eine Modell von etwas.
Ein konkretes Beispiel
Oft läuft mir das in Standard-Webanwendungen über den Weg in Form von Admin- und normaler Nutzer. Z.B. in einem Blog wie diesem ein Eintrag wie dieser. Es gibt folgende Fälle:
Der Besucher will den Eintrag lesen und kommentieren.
Der Text darf also nur lesbar sein und Kommentare müssen angehängt werden können. Wenn der Text in mehreren Sprachen vorliegt, muss der Text nur in der einen Sprache geliefert werden, die der Benutzer wünscht.
Der Autor will den Eintrag bearbeiten.
Der Text muss also Beschreibbar sein und Kommentare kommen hier gar nicht vor. Alle Texte in den bereits existierenden Sprachen müssen verfüg- und änderbar sein.
Das ist nur ein relativ kleiner Unterschied, aber allein die Sprache würde vieles verkomplizieren, wenn man beide Modelle in eine Klasse stopft.
Probleme bei der Umsetzung
Leider helfen viele aktuelle Techniken in diesem Sinne nicht weiter. Oft sieht man ORM-Entitäten, die direkt als Modell benutzt werden. Da wird das “mehrere Modelle für eine DB-Tabelle” schon schwer wenn nicht fast unmöglich. Flow3 und Doctrine2 sind da schon Ansätze, aber auch dort nur mit Mühe zu haben.
Vielleicht hilft das ja dem ein oder anderen weiter. Nur so nebenbei: falls irgendwer sich mal über DDD austauschen will, ich bin da sehr interessiert. Bisher hatte ich leider nur das Buch gelesen; und das ist schwer lesbar aber genial.