Business Domain Modelling

Ein paar Gedanken zum Entwurf einen Domain Models...

Ich frage mich, wie viele Designer und Architekten den Weg zu einem stabilen Domain Model finden welches losgelöst jeglicher Technologie ist und auf eine lange Zeit Bestand hat?

Nehmen wir einmal den Entwickler als erstes Beispiel: Der Entwickler arbeitet am Liebsten in der IDE seiner Wahl und findet sich am besten in der Sprache seiner Wahl zurecht, welche sich letztendlich in Code ausdrückt. Da er glaubt mit den neuesten Standards und Hypes bewandert zu sein, entwirft er ein super-duper Domain Model in Sourcecode (am Besten OO mit POJOs). Metadaten dürfen im Code natürlich auch nicht fehlen, zumal es die Frameworks ja sogar anbieten (Bsp. JPA Annotationen).

Recht schnell wird ihm klar, dass das Ganze doch recht komplex wird aber es stört nicht weiter, da sich immer noch alles abbilden lässt bzw. er der Macher ist und (mittlerweile als Einzigster) den Überblick behält.

Anforderungen wie Langlebigkeit und Wartbarkeit sind erstmal zweitrangig, auch wenn der JCP bereits einen Draft der Folgeversion vorgelegt hat. Neuen Teammembers dieses monolithische Geflecht einzelner Klassen zu erklären und auch die Notwendigkeit der Beziehungen untereinander aufzuzeigen ist ein Genuss, da er sein Modell kennt und Javadoc sein bester Freund. Nur versteht dies jeder? Versteht dies auch der Business Analyst der die Anforderungen definiert hat? Fraglich...

Phase 2:
Sei es ein Technologiewechsel oder ein Upgrade, es ist Zeit, dass der Macher sein Modell upgraded (denn er versteht es am Besten). Reine Fleissarbeit...

Phase 3:
Neue Anforderungen landen im Jira. Denkbar wäre, dass das Modell (oder Teile davon) in eine WSDL gepackt werden, oder generell in ein Schema, um einem Legacy System anbieten zu können. Also basteln wir kurzer Hand ein XMLSchema und natürlich auch die Parser/Writer dazu. Allerdings sind somit unsere eigentlichen Informationen des Business Models redundant und voneinander unabhängig geworden. Noch schlimmer wird es wenn jemand verlangt abhängig von unserem Modell DAO Code (sei es SQL oder Java) zu erzeugen, also bauen wir uns ein Freemarker Template und die nächste Redundanz ist da.

Das Problem was ich aufzeigen möchte ist folgendes: Ist das Business Model nicht das zentrale Herzstück der Anwendung bzw. des gesamten Unternehmens? Und sollte dieses Modell nicht auch von Stakeholders begriffen werden, die sich nicht in den Tiefen unserer Kodierungssprache bewegen? Sollten wir uns nicht einen Schritt von dem Code wegbewegen und nochmals über die Methodologie nachdenken?

Mögliche Lösungsansätze ohne an Code zu denken:

1) UML: Sicherlich interessant nur Overkill. Ich möchte nicht jedes kleinste Detail mit UML modellieren und immer wieder den One-Way-Generator laufen lassen um zu sehen, dass ich ein perfekter Designer bin und mit dem grünen Knopf mein Modell in Code giessen kann. Dies ist einfach nicht effizient genug und wie erwähnt in den allermeisten Fällen eine Einbahnstrasse.

2) Einfache Modellierungssprachen (wie Ecore/EMF) bieten genug um ein Modell anschaulich darzustellen und begreiflich zu machen. Hat man sein Ecore Modell auf dem Desktop ist es lediglich eine Frage des Generators (bzw. des Templates) um jegliche Anforderungen zu erschlagen. Selbst der Business Analyst wagt sich das Modell zu öffnen und findet sich damit zuerecht. Der Vorteil gegenüber vielen kommerziellen UML Tools liegt in den M2T und M2M Transformationen die ich nach Belieben entwerfen kann um zum Ziel zu gelangen.

Wer also die Problemstellung kennt sollte sich die Geschwister Ecore/EMF/Xpand/Xtext und oAW anschauen. Vielleicht hilft dies weiter...