Ein Modell ist nicht ein UML-Diagramme oder Teile des Codes. Es ist abstrakter. So kann man zum Beisplel eine alte Karte als ein geographisches Modell sehen - die alte chinesische Karte zeigt China in der Mitte und andere Plätze sind nur wenig detailiert und kleiner dargestellt. Auf einer modernen Karte sind dide Größen richtig, aber eine amerikanische Karte hat trotzdem die USA in der Mitte. Aber auch die Karte ist verzerrt: Grönland ist zum Beispiel zu groß (Mercator-Projektion), aber eine gerade Linie ist auch in der Realität eine gerade Linie, so dass es für Schiffs-Navigation günstig ist.
Ein Modell ist also ein System von Abstraktionen, die ausgewählte Aspekte einer Domain beschreiben und benutzt werden kann, um Probleme in dieser Domäne zu lösen. Darauf basierte eine ubiquitäre Sprache: Eine Sprache, die sich am Domänen-Modell orientiert und von allen Team-Mitgliedern benutzt wird, um die Aktivitäten der Mitarbeiter mit der Software zu verbinden.
Eric plädiert dafür, sich auf die Kern-Domäne zu fokussieren. Sie ist der Teil, der überhaupt dazu führt, dass man das System schreiben will. Die Kern-Domäne ist dann auch meistens der Grund, warum man die Anwendung nicht einfach kauft oder outsourct. Es ist eine Anwendung der 80-20-Regel: 80% des Werts kommen von 20% des Systems (oder sogar weniger).
Er berichtete dann aus einem Projekt: Zwei Systeme erbrachten die Supply Chain und die Anwwendungen wurden immer mehr miteinanderer verwoben. Neue Features sind schwierig. Ein Plan des Kunden war es, das System durch ein sauber System zu implementieren. Dazu solle in 3 Jahren abgelöst werden. Im ersten Jahr sollen die generischen Funktionen gebaut weden, dann die Legacy abgelöst werden und dann im dritten Jahr sollte es neue Feature geben. Erics Vorhersage war, dass im zweiten Jahr Dinge problematisch werden, weil das neue System schwierig abzulösen sein wird, weil es eben gewachsene Lösungen enthält. Außerdem wird es während der Ablösung weiterentwickelt, wodurch die Komplexität noch schwieriger wird. Dadurch wird die Anwendung nur eine Portierung der alten Anwendung, weil der Stress zunimmt und man die alte Funktionalitäten nicht sauber implementierne kann. Zudem wird das System sehr teuer sein und keine neuen Funktionalitäten haben - was politisch schwer zu verkaufen ist.
Die Firma will eigentlich die neuen tollen Features aus Jahr 3, was als letztes implementiert wird. Also: Man baut diese Sachen direkt in das alte System ein. Dadurch kann man die neuen Features während der Projektlaufzeit in das System einbauen und die Features aus Jahr 3 direkt umsetzten. Man muss dabei Teile der alten Anwendung refactoren, um das System passend erweitern zu können. Das kann dann aber auch in einen Hack ausarten, in dem man dann einfach nur die neuen Funktionalitäten "irgendwo" implementiert. Und das ist, was dann häufig einfach gemacht wird. Das geht aber nur bis zu einem gewissen Maße, bis man die Software nicht mehr wirklch ändern kann. Das Problem ist, dass viele Entwickler Dinge aufräumen wollen. Dadurch werden die Hacker, die sich auf die Kern-Domäne fokussieren, belohnt, weil sie mit der sauberen Infrasttuktur produktiver werden und gleichzeitig auf dieser Infrastruktur nicht besonders saubere Anwendungen bauen, dadurch die Infrastruktur "verschmutzen" und gleichzeitig den meisten Geschäftsnutzen erzeugen.
Also: Nicht alle große Systeme werden sauber designt sein. Das ist eine schlichte Realität - man muss lernen, sie zu akzeptieren. Also: Was soll man sauber designen? Natürlich die Kern-Domäne.
Und: Es gibt immer mehrere Modelle. Er führte dann den Begriff des Kontext ein: Das ist die Umgebung, in der ein Wort oder eine Aussage eine Bedeutung bekommt. Also macht ein Modell nur in seinem Kontext Sinn und man kann Dinge von einem Kontext in einen anderen übersetzen. (Context Map) Man kann eine Darstellung des Models von einer anderen Darstellung des Models entkoppeln, indem man einen Anti-Corruption-Layer einzieht, der das eigene System von der Darstellung in den anderen Systemen entkoppelt.
Zurück zu dem 3-Jahre-Projekt: Man baut also primär die neuen Features und baut eine kleine Infrastruktur, um das zu unerstützen und löst das Legacy-System nicht ab. Das Legacy-System wird durch einen Anti-Corruption-Layer abgekoppelt, das übrigens aufwändiger zu implementieren sein kann, als die eigentlichen Features. Der Aufwand ist dann aber immer noch geringer als bei den anderen Lösungen. Und man bekommt dadurch auch eine Antwort auf das Problem, dass Präzisions-Designs zerbrechlich sind - man muss sie durch die Anti-Corruption-Layer "sauber" halten.
Labels: Domain Driven Design, Eric Evans, SpringOne
¶ 12:04
