(27.02.06 08:40)

Ein ausdrucksstarkes und reichhaltiges Domänenmodell dient als Abstraktion einer Fachdomäne dazu, das Exemplarische der konkreten Anwendung einzufangen. Und zwar so, dass die gewählten Abstraktionen und Konzepte die Problemdomäne korrekt abbilden und eine einwandfreie Implementierung erlauben. Das setzt voraus, dass das Domänenmodell eine Synthese aus fachlichen und implementierungsrelevanten Aspekten bildet. Wir wollen hier den bedeutsamen Punkt einstweilen aussparen, dass es mit Hilfe von Domänen-spezifischen Sprachen (DSLs) möglich wird, die Ausdrucksstärke eines Domänenmodells weiter zu erhöhen, ohne die tatsächliche Implementierung zu vernachlässigen; dieses Thema verdient einen eigenen Beitrag, ja eigentlich ein ganzes Buch ;-).

Wir wollen uns hier mit der Frage beschäftigen, wie wir überhaupt zu einem ausdrucksstarken und reichhaltigen Domänenmodell gelangen können.

Um dies zu erreichen sind zwei Dinge wichtig:

Erstens, muss es zwischen den Fachvertretern und den Softwareentwicklern zu einem regen und fortwährenden Dialog kommen, der das gegenseitige Verständnis für die fachlichen und konzeptionellen Aspekte vertieft und Ausdruck in einer gemeinsamen Sprache findet, die vertiefte Einsichten in das Domänenmodell erlaubt. Um Eric Evans zu paraphrasieren: Die im Dialog ausgetauschten Informationen geben die Semantik des Modells wieder. Der Dialog nährt sich dabei aus dem Domänenmodell, stützt und treibt dessen Entwicklung aber gleichzeitig auch voran. Das Domänenmodell wandelt sich in dem Masse, wie das Verständnis für die Problemdomäne sich ändert bzw. wächst. Die Modellierung ist dabei darauf ausgerichtet, ein zunehmend vertieftes Verständnis des Problemraumes zu erlangen und durch griffige Abstraktionen das Konkrete und oft Widersprüchliche der Fachdomäne schlüssig einfangen und abbilden zu können. Je geringer die Zahl der dazu notwendigen Konzepte ist, und je einfacher sie sind, desto besser können wir auf neue und häufig überraschende Anforderungen und Einsichten reagieren, ohne die Integrität des Gesamtmodells zu gefährden und ohne die Ausdrucksstärke des Domänenmodells als Ganzes zu schmälern.

Zweitens, müssen die Entwickler in der Lage und fähig sein, auf der Basis vager und oft unvollständiger Informationen die Grundstruktur (der Ausdruck Architektur wird hier bewusst vermieden!) so zu legen, dass das detaillierte Domänenmodell daraus schrittweise entstehen kann. Das verlangt oft mutige Entscheidungen, die im Wissen darum gefällt werden, dass alles auch immer ganz anders sein könnte. Nicht zuletzt deswegen lohnt es sich, Lösungen so einfach wie möglich zu halten, ohne dabei ungebührlich zu vereinfachen. Gute Abstraktionen lassen das Richtige weg, sie berücksichtigen das Konkrete und reduzieren es auf dessen Essenz. Gleichzeitig berücksichtigen sie aber auch die tatsächliche Implementierung und schaffen so eine Synthese zwischen fachlicher Anforderung und deren Umsetzung. Denn: Ein brauchbares konzeptionelles Modell lässt sich ohne Berücksichtigung implementierungstechnischer Belange nicht bauen. Die Kunst besteht darin, die beiden Welten im Domänenmodell so zusammen zu führen, dass keine ungewollte Komplexität entsteht. Hier können – wie bereits angetönt – DSLs helfen, da sie eine ausdrucksstarke Form der Metaprogrammierung erlauben, bei der die Details ausgedrückt durch die DSL in den Daten liegen und die Abstraktion im Code; letzterer wird entweder aktiv aus der verwendeten DSL generiert oder zur Laufzeit direkt durch die DSL zum Beispiel mit Hilfe eines DSL-Interpreters getrieben.

Ein gutes Domänenmodell zu entwickeln ist nicht einfach. Es braucht Hingabe, Disziplin und den Mut, Fehler zu begehen. Denn manchmal muss man leider in einer Sackgasse landen, um die passende Lösung zu finden; das ist frustrierend, erlaubt aber auch immer wieder überraschende Erkenntnisse. Wer sich also zusammen mit den Domänenexperten auf die spannende Reise zu tiefen Einsichten in die Fachdomäne einlässt, der wird nicht nur viel Inspirierendes und manches Aha-Erlebnis erfahren, sondern auch mit einem Domänenmodell und letztlich einer Software belohnt, die tut, was sie soll und erst noch weiterentwickelt werden kann.

-nemo :-)

Über diesen Artikel diskutieren.

Zugriffe heute: 2 - gesamt: 3092.