2016-06-30 5 views
2

Zitiert Evans blue bookDDD Wertobjekte

Es mag Sie überraschen zu erfahren, dass wir sollte nach Möglichkeit mit Wert Objekte anstelle von Entitäten zu modellieren streben. Auch wenn ein Domänenkonzept als Entität modelliert werden muss, sollte das Design der Entität so ausgerichtet sein, dass es als Wertcontainer und nicht als untergeordnete Entitätscontainer dient. Dieser Hinweis basiert nicht auf einer willkürlichen Präferenz. Werttypen, die Dinge messen, quantifizieren oder beschreiben, sind einfacher zu erstellen, zu testen, zu verwenden, zu optimieren und zu warten.

Um es in meinem Zusammenhang gestellt, ich habe

  • Rechnung Aggregate, die als AR
  • Emittent Gesamtrechnungs Entity hat die Emittentin Entity hat als AR

Jede Rechnung es hat Emittent. Sollte ich dies als eine Rechnung-> Issuer-Beziehung über ID behandeln, oder ist es eine bessere Vorgehensweise, dies als ein Value Object mit einem Verweis auf den Emittenten zu behandeln, oder diesen Aussteller einfach als ein von der Emittentin AR

erstelltes Wertobjekt zu behandeln Also in diesem Fall wäre es

1.

Invoice 
    -InvoiceId 
    -IssuerId 

VS

Invoice 
-InvoiceId 
-InvoiceIssuer 
    -IssuerId 
    -FullName 

VS

Ich lehne mich nach der Lösung Nummer 2, weil, wenn sich der Name der Emittentin aus irgendeinem Grund ändert, ich noch einen Namen der Emittentin zum Zeitpunkt der Rechnungserstellung und einen Verweis auf Aussteller, der seinen Namen geändert hat.

Logik dahinter ist, wenn ich versuche, eine alte Rechnung zu drucken, nachdem der Emittent seinen Namen geändert hat, habe ich immer noch Rechnung in seinem alten Zustand, da es so an erster Stelle gedruckt wurde, aber wenn ich noch werde in der Lage sein, alle Rechnungen dieses Ausstellers zu finden, auch wenn er seinen Namen geändert hat.

Ist die Erstellung von Value Objects mit einem Verweis auf eine andere Entität nach ID gültigen Ansatz, oder mache ich in diesem Fall etwas falsch?

+0

Wo sind Ihre beschränkten Kontexte? –

+0

Bounce Kontext ist Accounting, die aus Rechnungen, Empfänger, Emittenten, VatTypes usw. besteht. – Robert

+1

Innerhalb eines BC würde ich (2), sonst (1) verwenden. Die Frage bleibt jedoch weiterhin, wie Sie den Namen aggregiert aktualisieren möchten. Die Antwort scheint naheliegend - verwenden Sie nur Domänenereignisse, bis Sie die Tatsache treffen, dass Sie zwei verschiedene Aggregate haben, und nach dem Buch ist Ihr Aggregat die Transaktionsgrenze. Sie haben also das Risiko, dass ein Aggregat aktualisiert wird und das andere nicht. –

Antwort

3

„ist Neigung torwards Lösung Nummer 2, becasue wenn der Name des Emittenten jemals aus irgendeinem Grunde ändert, werde ich immer noch einen Namen der Emittentin zum Zeitpunkt der Rechnungserstellung habe, und ein Verweis auf Emittent, geändert sein Name. "

Sie haben die Frage bereits selbst beantwortet. Das einzige Modell, das die obigen Anforderungen erfüllt, ist # 2.

Es gibt definitiv Modellierung Best Practices, die Sie verfolgen können (bevorzugen Wertobjekte, Design kleine Aggregate, etc.), aber am Ende ist DDD über das Erstellen domänenspezifische Modelle und ein solches Modell kann nur kritisiert und hat nur einen Wert im Kontext seiner Problemdomäne.

Wenn Sie versuchen, Ihr Modell zu validieren, konzentrieren Sie sich zuerst auf die geschäftlichen Verhaltensweisen & Invarianten.