Was ich über domänenorientiertes Design weiß

DDD 101

Je größer das Projekt, desto schwieriger ist es, es zu pflegen. Eine Möglichkeit, dies zu vermeiden, ist die Aufteilung der Anwendung in kleinere Bereiche entsprechend ihren Geschäftsregeln, die als Domänen bezeichnet werden.

Grundlegend ist eine Domäne ein Wissensgebiet, das entweder öffentlich ist, wie die Schachregeln, oder privat, wie die Geschäftsregeln einer gemeinnützigen Organisation.

Eine komplexe Domäne verwendet wahrscheinlich Wissen aus anderen Domänen. Eine gemeinnützige Organisation, die online Schach unterrichtet, wird zum Beispiel über Schach, das Unterrichten über Online-Plattformen und, auch wenn Sie nicht als Student berechnet werden, über ihre Finanzen Bescheid wissen.

Jede Unterdomäne Ihrer Domäne ist in DDD als begrenzter Kontext bekannt, jede hat ihr eigenes Modell der Welt, das mit spezialisierten Codeeinheiten, den so genannten Bausteinen, aufgebaut ist. Hier werde ich mich auf Entitäten und Wertobjekte konzentrieren, die beide als Objekte referenziert werden können.

Entitäten sind Objekte, die innerhalb der Domäne eindeutig sein sollen. Dies wird erreicht, indem eine oder mehrere Eigenschaften verwendet werden, um eine bestimmte Entität zu identifizieren. Beispielsweise werden zwei Benutzer, die denselben Namen in einem System verwenden, immer unterschiedliche E-Mails haben, da E-Mails nicht wiederholt werden können – meistens werden Entitäten durch eine Kennung und manchmal durch eine Kombination von Eigenschaften unterschieden.

Wert-Objekte hingegen haben keine Identität, so dass nur ihre Eigenschaften zur Unterscheidung zwischen zwei Instanzen verwendet werden können. Nehmen wir zum Beispiel zwei Schachfiguren: Sie sehen gleich aus, wenn sie aus demselben Spielsatz stammen und dieselbe Farbe haben, so dass es egal ist, wenn man sie vertauscht. In DDD sind Werte-Objekte unveränderlich, so dass es einfacher ist, mit ihnen zu argumentieren.

Datenintegrität

Ein begrenzter Kontext legt nicht alle seine Objekte offen, um seine Datenintegrität zu garantieren. Stattdessen legt er einige Aggregatwurzeln als eine Art öffentliche Schnittstelle zu sich selbst offen.

Ein Aggregat ist nichts anderes als eine Entität, die aus anderen Objekten zusammengesetzt ist. Genauer gesagt ist ein Aggregat eine Ansammlung zusammengehöriger Objekte, die wir beim Ändern von Daten als eine Einheit behandeln.

In der Praxis nehmen Aggregate die Form der als Baum bekannten Datenstruktur an. Aus diesem Grund haben alle Aggregate eine Wurzel.

Das einzige Mitglied eines Aggregats, auf das sich andere Objekte beziehen können, ist seine Wurzel, und das ist es, was wir offenlegen. Das wird so gemacht, weil es andere Objekte daran hindert, Daten auf eine Art und Weise zu verändern, die das Aggregat nicht kontrollieren kann.

Es ist wichtig klarzustellen, dass ein gebundener Kontext viele Aggregate verwenden kann, auch wenn ihre Wurzel nicht direkt nach außen hin offengelegt wird.

Der Umgang mit mehreren gebundenen Kontexten

Aber die Dinge können noch komplizierter werden, oder? Jeder begrenzte Kontext erhält ein leicht unterschiedliches Modell der gleichen Objekte, mit unterschiedlichen Eigenschaften und Verhaltensweisen. So kann ein Benutzer in einem Spielkontext eine Eigenschaft haben, um seinen Punktestand zu verwalten, die in einem Finanzkontext irrelevant ist und daher nicht existiert.

Und das ist noch nicht alles. Es ist auch möglich, dass ein Domänenkonzept, das in einem begrenzten Kontext als Entität repräsentiert wird, in einem anderen Kontext als Objektwert repräsentiert wird, oder einfach ganz weggelassen wird.

Während zum Beispiel der Unterrichtskontext erfordert, dass Lehrer als Entitäten dargestellt werden, damit sie den Schülern durch ihre IDs zugeordnet werden können, zieht es der Finanzkontext vor, „Lehrer“ als einen Wert für die Positionseigenschaft der Entität „Mitarbeiter“ zu sehen.

Einige andere DDD-Bausteine sind Dienste, Repositories, Fabriken und Ereignisse. Ich werde versuchen, sie kurz zu beschreiben.

Dienste sind Fähigkeiten einer Domäne, die nicht natürlich zu Entitäten oder Objektwerten passen. Achten Sie darauf, dass es sich um Domänendienste handelt, nicht um Anwendungs- oder Infrastrukturdienste.

Repositories sind Brücken zu Speichereinheiten – hallo CRUD!.

Factories sind Methoden zur Erstellung von Domänenobjekten, damit diese nie ungültige Werte haben. Dieser Teil hat mich dazu gebracht, über produktgesteuerte Tests nachzudenken.

Ereignisse sind Objekte, die etwas repräsentieren, das in der Domäne passiert ist – die Experten kümmern sich um sie. Großartige Möglichkeiten für die Erstellung einer ereignisgesteuerten Anwendung.

Auch wenn ich mich nicht daran erinnere, dass Evans das so gesagt hat, sind begrenzte Kontexte eine gute Möglichkeit, Ihren Code in Microservices aufzuteilen, wobei jeder Service ein eigener Kontext ist. Der erste Schritt könnte eine „virtuelle“ Aufteilung sein, bei der jeder Kontext in einem anderen Modul derselben Anwendung untergebracht wird, und wenn man dann feststellt, dass sie wirklich isoliert sind, kann man sie in andere Module verschieben.

Eine Sprache, die für alle gilt

Eines der ersten Dinge, die man beim Studium von DDD lernt, ist, dass man sein System mit einer allgegenwärtigen Sprache beschreiben sollte. Das heißt, wir sollten Code mit denselben Verben (für Methoden oder Dienste) und Substantiven (für Objekte) schreiben, die die Fachexperten verwenden, wenn sie mit uns sprechen.

Das Schreiben von Code auf diese Weise hat den Vorteil, dass es die Kommunikationslücke zwischen Entwicklern und Fachleuten schließt, wenn sie sich unterhalten, aber es ist eine zu starke Vereinfachung des wirklichen Lebens, daher verwende ich persönlich es als Richtlinie, aber nicht als endgültige Lösung.

Ich habe es mir bis zum Schluss aufgespart, weil ich das Wichtigste über DDD normalerweise nicht lese, da es im „komplexen“ Teil des Buches steht.

Neulich habe ich erfahren, dass der Autor selbst gesagt hat, dass die Reihenfolge, in der er die Dinge im Buch präsentiert, nicht optimal ist, und dass das, was ich hier beschrieben habe, näher an dem ist, was ideal gewesen wäre 😍. Ich habe es in einem Podcast gehört, der sich auf dieses Buch bezieht