Domain Model #

Das Domain Model ist nach Larman¹ ein Herzstück der objektorientierten Analyse. Es ist vor allem ein Kommunikationsmittel, nicht ein Design-Zwischenschritt vor der Programmierung. Larman¹ bezeichnet es auch als visuelles Wörterbuch.

Es soll also nicht eine 1:1 Darstellung vom Code sein, sondern die Entwickler unterstützen, so dass sie die Domäne besser verstehen und somit Fehler fehlende Inhalte in einer Spezifikation finden.

Da das Domain Model die statische Seite beschreibt, wird oft auch eine Darstellungsform für die Dynamik des Systems benötigt. Dafür bieten sich unter anderem die Use Cases oder Sequenzdiagramme an.

Vorteile und Nachteile von Domain Models:

• In einem Domain Model können die Fachbegriffe bereits mit der Businessabteilung geklärt und definiert werden. Dadurch wird schon früh eine gemeinsame Terminologie entwickelt.
• Das Modell kann gut aus Kundensicht erstellt werden. Haben wir den Kunden verstanden?
• Es ist ersichtlich, was genau gespeichert wird und dann auch erreichbar sein muss.
• Die dynamischen Aspekte sind nicht ersichtlich.
• Es kann kein Änderungsvergleich eines Diagrammes gemacht werden. Es kann also nur eine einzelne Person das Diagramm bearbeiten.
• Duplizierte Information lässt sich leicht im Code finden. In einem Diagramm ist es nicht so einfach.
• Das Diagramm muss eine normierte Bedeutung haben, damit es keine Missverständnisse gibt.
• Es sollte in einer Teamarbeit erstellt, also nicht nur per Mail herumgeschickt werden. Bei der Erstellung gibt es wertvolle Fragen und Antworten.
• Ein Domain Model in der Grösse eines A3 Blattes ist gut lesbar auf einem Beamer.

Im obigen Beispiel ist unter anderem ersichtlich, dass ein Kunde mehrere Reservationen machen kann. Jeder Reservation sind mehrere Artikelbeschreibungen zugeordnet. Bei der Reservation ist noch nicht das genaue Produkt entscheidend sondern nur die Art beziehungsweise hier die Artikelbeschreibung.