Wertobjekte in CQRs - wo zu verwenden

Question

Nehmen wir an, wir haben eine CQRS-inspirierte Architektur mit Komponenten wie Befehlen, Domänenmodell, Domänenereignissen, Lesemodell-DTOs.
Natürlich können wir Wertobjekte in unserem Domänenmodell verwenden. Meine Frage ist, falls sie auch verwendet werden, in:

1. Befehle
2. Veranstaltungen
3. Dtos

Ich habe keine Beispiele gesehen, bei denen Value -Objekte (VO) in den oben genannten Komponenten verwendet werden. Stattdessen werden primitive Typen verwendet. Vielleicht sind es nur die simplen Beispiele. Schließlich ist mein Verständnis der VOS -Verwendung in DDD, dass sie als Klebstoff für die gesamte Anwendung fungieren.

Meine Motivation:

Befehle.
Nehmen wir an, Benutzer reicht ein Formular ein, das Adressfelder enthält. Wir haben Adresswertobjekte, um dieses Konzept darzustellen. Wenn wir den Befehl im Client konstruieren, sollten wir trotzdem die Benutzereingabe validieren. Wenn er gut geformt ist, können wir direkt dort Adressobjekt erstellen und den Befehl damit initialisieren. Ich sehe keine Notwendigkeit, die Erstellung eines Adressobjekts an Befehlshandler zu delegieren.

Domänenereignisse.
Das Domänenmodell arbeitet bereits in Bezug auf Wertobjekte. Durch die Veröffentlichung von Ereignissen mit VOS können wir einen Mapping -Code vermeiden, anstatt sie in primitive Typen zu konvertieren. Ich bin mir ziemlich sicher, dass es in diesem Fall in Ordnung ist, VOS zu verwenden.

Dtos.
Wenn unsere Abfragen-DTOs Wertobjekte enthalten können, ermöglicht dies eine gewisse Flexibilität. ZB, wenn wir Geldobjekt haben, können wir wählen, ob wir es in EUR oder USD oder USD anzeigen möchten, nicht erforderlich, um das Lesemodell zu ändern.

Answer 1

Ok, ich habe meine Meinung geändert. Ich habe in letzter Zeit versucht, mit VOS ein Haufen zu tun http://www.infoq.com/presentations/value-objects-dan-bergh-johnsson Es hat ein paar Dinge für mich geklärt.

Befehle und Ereignisse sind Nachrichten (und nicht Objekte, Objekte sind Daten + Verhalten).

Wertobjekte sind überhaupt nicht wie DTOs. Sie sind eine Domänenrepräsentation und sind im Allgemeinen reich an Verhalten wie allen anderen Domänendarstellungen.

Befehle und Ereignisse kommunizieren Informationen in und aus der Domäne, aber sie verkörpern kein Verhalten. Aus dieser Perspektive scheint es falsch zu sein und möglicherweise eine Verletzungskontextgrenzen, um VOS in ihnen zu bestehen.

Um Oren zu paraphrasieren (obwohl er sich auf Nhibernate und WCF bezieht) "senden Sie Ihre Domäne nicht über den Draht".http://ayende.com/blog/archive/2009/05/14/the-stripper-pattern.aspx

Wenn Sie ein Wertobjekt kommunizieren möchten, schlage ich vor, die erforderlichen Attribute zu übergeben, die erforderlich sind, um die VO in ihnen neu zu konstruieren.

Originaltext (für die Nachwelt):

Wenn Sie fragen, ob Value -Objekte vom Domänenmodell an Ereignisse übergeben oder von Befehlen übergeben werden können, sehe ich kein großes Problem mit dem ersteren, obwohl letztere möglicherweise gegen einige der Regeln der Gesamtwurzel verstoßen, die die sind "Eigentümer" der Werte.

Das heißt, ein Wertobjekt repräsentiert Konzepte wie zum Beispiel eine Farbe. Du nicht haben Grün, du sind grün oder nicht. Es scheint nichts an sich zu geben, wenn ein Befehl Ihnen sagt, dass Sie grün sind, indem Sie dies übergeben.

Das Lesen des Kapitels von DDD auf dem aggregierten Wurzelmuster erläutert Entitäten und Wertobjekte recht gut und es lohnt sich, ein paar Mal gelesen zu werden.

Answer 2

Ich sage, es ist eine schlechte Idee.

Es gibt einen Grund, warum wir nicht dasselbe mit Entitäten tun - um zu vermeiden, dass andere Teile des Systems mit der Domäne (an den falschen Stellen) gekoppelt werden. Gleiches gilt für Werteobjekte. Die einzige Differenz zwischen Wertobjekten und Entitäten ist lebenslang und Eigentum - diese Unterschiede beeinflussen nicht, wie wir sie für sie koppeln sollten und nicht.

Stellen Sie sich vor, Sie machen eine Veranstaltung eine VO. Eine Änderung Ihrer Domain erfordert, dass Sie diese VO ändern. Sie haben sich jetzt in eine Ecke gepackt, in der sich auch Ihre Veranstaltung befindet gezwungen Um sich zu ändern, dito für alle Befehle oder DTOs ist ein Teil von.

Dies ist zu vermeiden.

Verwenden Sie DTOs und/oder Primitive. Zeichnen Sie sie ab (Automapper macht es zu einem 1-Zeilen-Angebot).

Answer 3

Ähnlich wie bei anderen Antworten würde dies in SOA die Kapselung des Dienstes durchbrechen, wenn die Domäne jetzt austritt.

Answer 4

Entsprechend Clean Code Ihre DTOs sind Datenstrukturen (nur um einen weiteren Term hinzuzufügen), während Wertobjekte Objekte sind. Der Unterschied, dass Objekte Verhalten haben können. Das Mischen von Datenstrukturen mit Objekten ist im Allgemeinen eine sehr schlechte Idee, da es schwierig ist, den von Ihnen erhaltenen Hybrid aufrechtzuerhalten.

Ich fühle mich nicht richtig, um DTOs auch aus der Sicht der Architektur Wertobjekte zu versetzen. Die Wertobjekte befinden sich innerhalb des Domänenmodells, während die von Ihnen erwähnten DTOs die Schnittstelle des Modells definieren. Normalerweise bauen wir eine Schnittstelle auf, um die Außenwelt von innen von etwas zu entkoppeln. Im aktuellen Fall haben wir DTOs hinzugefügt, um die äußere Welt von den Wertobjekten (und anderen modellbezogenen Dingen) zu entkoppeln. Danach ist es verrückt, Wertobjekte zur Schnittstelle zu verleihen.

Sie haben diese Lösung also noch nicht getroffen, weil es sich um ein Anti-Muster handelt.