Talk nerdy to me

Ein Domain-Modell ist ein Tool, mit dessen Hilfe ein konzeptionelles Verständnis für ein Produkt oder ein System geschaffen werden kann. Es untersucht die verschiedenen Komponenten, die man für ein Produkt oder für ein System braucht und setzt diese in eine Beziehung. Dabei können unter den Komponenten unterschiedliche Beziehungen bestehen. Beispielsweise in einem Unternehmen gibt es viele Mitarbeiter und ein paar wenige Abteilungen. Da nicht alle Mitarbeiter in allen Abteilungen arbeiten, sondern auf die einzelnen Abteilungen aufgeteilt werden, besteht zwischen Mitarbeitern und einer Abteilung, eine 1 zu „many“ Beziehung.

Dabei hilft das Domain-Modell enorm, um beispielsweise komplexe Zusammenhänge auf eine einfache Art und Weise darzustellen, die für jedermann sehr leicht verständlich ist und auf die man immer wieder zurückgreifen kann. Gerade bei kniffligen Herausforderungen empfehle ich, sich erst ein Domain-Modell zu erschaffen, um alle Aspekte berücksichtigen zu können. Das nachfolgende Beispiel, soll euch helfen, das Domain-Modell besser zu begreifen und aufzuzeigen, wo und wie man es am besten anwenden kann:

Ihr habt schon stundenlang an Besprechungen teilgenommen, um eine bestimmte Herausforderung zu diskutieren. Dennoch habt Ihr und Eure Teammitglieder weder über das Problem noch über die Lösung effektiv diskutiert. Um effektiv zu sein und weiterzukommen, muss das Team einen Schritt zurückgehen und klarlegen, wie jeder und jede die verwendeten Begriffe und der Ausgangssituation versteht. Zusätzlich muss reflektiert werden, auf welchen Ebenen diskutiert wird.

Wenn man feststeckt während einer Projektphase wird auch „the gnarly part“ (knorriger Teil) genannt. Dieser wird unabhängig von der gewählten Methodik oder dem Fachwissen sehr wahrscheinlich irgendwann erreicht. Hierbei kann sehr oft ein Domain-Model weiterhelfen.

Eine Technik, die gerne verwendet wird, wenn Projektteams feststecken und nicht mehr vorwärts kommen, ist das Business-Domain-Model. Es repräsentiert logisch die vom System zu erfüllenden Geschäftskonzepte und deren Beziehung zueinander. Es sollte nicht mit einem Datendiagramm verwechselt werden, das das tatsächliche Datenbankdesign oder die Architektur darstellt. Obwohl sie möglicherweise ähnlich aussehen, sollten in einem Domain-Diagramm Begriffe verwendet werden, die sich im Business-Model wiederfinden, damit jeder weiß von was derjenige gerade spricht. Im Folgendem möchte ich näher darauf eingehen, welche Funktionen ein Domain-Model hat und wie man es einsetzen kann.

Ein Domain Model besteht aus drei Komponentent, die ihr auf dem unteren Bild gut erkennen könnt. Es besteht aus Entities, Attributes und Associations. Die Verbindungen, die zwischen den Entities bestehen können aus einer 1:1 Beziehung oder eine 1:* (das * steht für „many“) Beziehung bestehen.

Das folgende Beispiel zeigt die verschiedenen Entities (Überbegriffe) der Einrichtung und weitere Begrifflichkeiten, die unter den Entities stehen, wie beispielsweise beim Trainer — Full name und Email adress. Diese Begriffe werden als Attributes klassifiziert.

Hier ist die Reise aber noch nicht zu Ende, jetzt kommen wir zum wichtigsten Teil und das sind die Verbindungen untereinander. Denn dadurch kann der Knoten aufgelöst werden und den Teammitgliedern ein gleiches Verständnis näher gebracht werden, an dem man sich orientieren kann. Auf diesem Bild sieht man schon sehr gut, wie die unterschiedlichen Entities miteinander verbunden sind.

Am Beispiel der „Registration“ und den „ScheduledCourse“ kann gezeigt werden, dass viele Registrierungen auf einen Kurs fallen: 30 Registrierungen sind für den Kurs „Content Marketing“ eingegangen.

Die Felder stellen Entitäten oder Geschäftskonzepte dar, und die Linien zwischen ihnen untersuchen die Beziehungen zwischen den einzelnen Konzepten. In jedem Feld sollen die Schlüsseldatenelemente enthalten sein, da sie Teil des Geschäftskonzepts sind.

Durch dieses Gesamtkonzept des Domain-Modellings und das aufdröseln der verschiedenen Komponenten kommt man sehr gut auf einen gemeinsamen Nenner, der die Diskussionen überflüssig macht und man sehr gut vorankommt.

Dadurch lässt sich manche Probleme gut erkennen und somit entsprechende Lösungsansätze ableiten, wie man mit verschiedenen Komponenten umgehen soll. Denn vielleicht erkennt man auch das eine Entity überflüssig ist, da sie eigentlich zu keiner anderen Entity wirklich verbunden ist.

Probiert es aus! Cheers!

Scott Wlaschin (2018): Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F#

Related posts:

Social media has become the pedestal in regards to how we communicate, build relationships and advertise our businesses, if used for the correct reasons it can have many benefits but unfortunately…

no prop for your storied pomp, her silent lips assumed consent to signifying nothing. don’t mistake this new colossus for just any old glory — mater peregrinorum stakes claims not to territory but…

Siasync is a new utility that will monitor a folder and synchronize its contents to the Sia network. As new files are created or removed it will keep Sia in sync with the local source folder. Siasync…