Domain-Driven Design Revisited

Kürzlich habe ich ein Buch mit dem Titel Domain-Driven Design von Eric Evans gelesen. Dies war nicht das erste Mal, dass ich dieses Buch las, aber dieses Mal wurde mir klar, dass ich mich in Bezug auf domänengesteuertes Design völlig geirrt hatte.

Ich dachte, dass das Domänenmodell aus Entitäten und Wertobjekten besteht. Tatsächlich war ich besessen davon, die Domänenlogik auf Entitäten und Wertobjekte zu verschieben. Ich wollte es so sehr tun, dass ich eine entscheidende Warnung ignorierte.

Mein Code war sauberer als früher, aber ich hatte immer das Gefühl, dass mir etwas fehlt .

Als ich das zweite Mal Domain-Driven Design las, wurde mir klar, was ich verpasst hatte.

Die Bausteine ​​eines Domänenmodells

Mein Fehler war, dass ich so besessen von Entitäten und Wertobjekten war, dass ich die anderen Bausteine ​​eines Domänenmodells vergaß .

Domain-Driven Design beschreibt das Domänenmodell wie folgt:

Ein Domänenmodell ist kein bestimmtes Diagramm; es ist die Idee, die das Diagramm vermitteln soll. Es ist nicht nur das Wissen im Kopf eines Domänenexperten; es ist eine streng organisierte und selektive Abstraktion dieses Wissens. Ein Diagramm kann ein Modell darstellen und kommunizieren, ebenso wie sorgfältig geschriebener Code oder ein englischer Satz.

Das Lesen dieser Definition hat meine Meinung jedoch nicht geändert. Als ich es las, war ich sogar stolz auf mich, denn es schien zu bestätigen, dass ich das Richtige tat.

Dann fing ich an, den zweiten Teil des Buches zu lesen, in dem es um die Bausteine ​​eines modellgetriebenen Designs ging, und das Kartenhaus, das ich so sorgfältig gebaut hatte, fiel auseinander.

Dieser Teil argumentiert, dass das modellgetriebene Design die folgenden Bausteine ​​hat:

• Entitäten sind Objekte, die durch ihre Identität definiert sind. Mit anderen Worten, wenn ein Objekt eine Identität hat, die während seines gesamten Lebenszyklus unverändert bleibt, sollte dieses Objekt als Entität modelliert werden.
• Wertobjekte beschreiben eine Eigenschaft einer Sache, und sie haben keine eigene Identität oder einen eigenen Lebenszyklus. Häufig ist ihr Lebenszyklus an den Lebenszyklus einer Entität gebunden.
• Dienste enthält Operationen, die nicht zu Entitäten oder Wertobjekten gehören. Wenn das Hinzufügen einer Operation zu einer Entität oder einem Wertobjekt für Sie nicht natürlich erscheint, stehen die Chancen gut, dass Sie diese Operation zu einem Dienst hinzufügen sollten.
• Module (Pakete) werden verwendet, um die kognitive Überlastung zu reduzieren. Sie geben einem Entwickler die Möglichkeit, entweder die Interna eines einzelnen Moduls zu untersuchen, ohne auf andere Module zu achten, oder die Beziehungen zwischen Modulen zu untersuchen, ohne sich um die Implementierungsdetails zu kümmern.
• Aggregate sind Gruppen von Objekten, die als eine Einheit behandelt werden. Jedes Aggregat hat ein Wurzelobjekt, das verwendet wird, um auf die anderen Objekte des Aggregats zuzugreifen. Jedes Aggregat hat auch eine Grenze, die definiert, welche Objekte zu dem betreffenden Aggregat gehören.
• Fabriken werden verwendet, um die Erstellungslogik eines Objekts oder eines Aggregats zu kapseln. Factories sind nützlich, wenn die Erstellungslogik kompliziert ist oder zu viel über die interne Struktur des erstellten Objekts verrät.
• Repositorys werden verwendet, um Entitäten aus dem verwendeten Datenspeicher zu holen und die Informationen der Entitäten darin zu speichern.

Nachdem ich das Buch beendet hatte, blieb mir nichts anderes übrig, als zuzugeben, dass ich keine Ahnung hatte, was domänengetriebenes Design wirklich ist.

Die gute Nachricht ist, dass ich noch viel Zeit zum Lernen habe.

Was habe ich gelernt?

Das Größte, was ich gelernt habe, als ich das Domain-Driven Design zum zweiten Mal gelesen habe, sollte jetzt ziemlich offensichtlich sein, aber ich habe auch ein paar andere Lektionen gelernt:

• Ich habe den Unterschied zwischen den Anwendungsdiensten und den Domänendiensten verstanden. Anwendungsdienste koordinieren die Aufgaben und delegieren die Arbeit an Domänenobjekte. Domänendienste implementieren Operationen, die nicht zu Entitäten oder Wertobjekten gehören. Mit anderen Worten, Anwendungsdienste enthalten keine Geschäftslogik und Domänendienste enthalten sie.
• Ich habe verstanden, dass das Domänenmodell keine exakte Kopie der Realität sein muss. Ich kann einfach die Teile der Realität auswählen, die für mich nützlich sind, und den Rest vergessen. Dies erscheint zunächst offensichtlich, kann aber auch sehr leicht vergessen werden.

Mein nächster Schritt ist, mehr über domänengetriebenes Design zu erfahren. Genauer gesagt möchte ich herausfinden, wie ich diese Bausteine ​​in meiner täglichen Arbeit einsetzen kann. Deshalb habe ich mir bereits Implementing Domain-Driven Design von Vaughn Vernon bestellt.

Was ist Ihr nächster Schritt?