CQRSの値オブジェクト - 使用する場所

Question

コマンド、ドメインモデル、ドメインイベント、読みモデルDTOなどのコンポーネントを備えたCQRSにインスパイアされたアーキテクチャがあるとしましょう。
もちろん、ドメインモデルで値オブジェクトを使用できます。私の質問は、それらも使用される場合です。

1. コマンド
2. イベント
3. DTO

上記のコンポーネントで値オブジェクト（VO）が使用されている例を見たことはありません。代わりに、プリミティブタイプが使用されます。たぶんそれは単純な例です。結局のところ、DDDでのVOSの使用についての私の理解は、それらがアプリケーション全体の接着剤として機能することです。

私の動機：

コマンド。
ユーザーがアドレスフィールドを含むフォームを送信するとしましょう。この概念を表すアドレスバリューオブジェクトがあります。クライアントにコマンドを構築するときは、とにかくユーザー入力を検証する必要があります。また、それが適切に形成されたら、アドレスオブジェクトを作成してコマンドを初期化することができます。アドレスオブジェクトの作成をコマンドハンドラーに委任する必要はないと思います。

ドメインイベント。
ドメインモデルはすでに値オブジェクトの観点から動作しているため、プリミティブタイプに変換する代わりにVOSでイベントを公開することにより、マッピングコードを回避できます。この場合、VOSを使用することは大丈夫だと確信しています。

DTO。
クエリ側のDTOがバリューオブジェクトを含めることができる場合、これにより、さらに柔軟性が可能になります。たとえば、Money Objectがある場合、EURで表示するかUSDで表示するか、読み取りモデルを変更する必要はありません。

Answer 1

わかりました、私は私の心を変えました。私は最近、これを見た後、vos a bunchに対処しようとしています http://www.infoq.com/presentations/value-objects-dan-bergh-johnsson それは私にとっていくつかのことを明らかにしました。

コマンドとイベントはメッセージ（オブジェクトではなく、オブジェクトはデータ +動作です）であり、DTOとよく似た点で、イベントに関するデータを伝え、動作をカプセル化しません。

値オブジェクトは、DTOとはまったく似ていません。それらはドメイン表現であり、一般的に言えば、他のすべてのドメイン表現と同様に行動に豊富です。

コマンドとイベントは、それぞれ情報をドメインに通知しますが、それ自体が動作をカプセル化しません。その観点から、それは間違っているようであり、おそらくそれらの内側のVOを渡すための違反の文脈の境界です。

Orenを言い換えると（彼はNhibernateとWCFに言及していましたが）「ワイヤー全体にドメインを送信しないでください」。http://ayende.com/blog/archive/2009/05/14/the-stripper-pattern.aspx

値オブジェクトを通信したい場合は、代わりにVOを再構築するために必要な属性を渡すことをお勧めします。

元のテキスト（後世の場合）：

バリューオブジェクトをドメインモデルでイベントに渡すことができるか、コマンドで渡されるかを尋ねている場合、前者に大きな問題はありませんが、後者は集計ルートのルールの一部に違反する可能性があります。価値の「所有者」。

それは、バリューオブジェクトは、たとえば色のような概念を表していると述べています。あなたはそうしない 持ってる 緑、あなた それは 緑かどうか。これを渡すことであなたが緑であることをあなたに伝えるコマンドに本質的に間違っていることは何もないようです。

集計ルートパターンでDDDから章を読むと、エンティティとバリューオブジェクトが非常によく説明されており、数回読む価値があります。

Answer 2

私はそれが悪い考えだと言います。

エンティティで同じことをしない理由があります - システムの他の部分をドメインに結合しないように（間違った場所）。同じことが値オブジェクトにも当てはまります。値オブジェクトとエンティティの唯一の違いは、生涯と所有権です。これらの違いは、私たちがそれらに適合させるべきではない方法に影響しません。

イベントにVOが含まれていると想像してください。ドメインの変更には、そのVOを変更する必要があります。あなたは今、あなたのイベントがあるコーナーに自分自身を箱に入れました 強制 変更するには、コマンドやDTOの一部についても同じです。

これは避けるべきです。

DTOおよび/またはプリミティブを使用します。それらをマップします（AutomApperは1行の取引を行います）。

Answer 3

他の答えと同様に、SOAでは、ドメインが漏れているため、これはサービスのカプセル化を破るでしょう。

Answer 4

によると クリーンコード DTOはデータ構造です（別の用語を追加するためだけに）、値オブジェクトはオブジェクトです。オブジェクトが動作を持つことができる違い。データ構造をオブジェクトと混合することは、一般的に非常に悪い考えです。なぜなら、あなたが得るハイブリッドを維持するのは難しいからです。

アーキテクチャの観点からも、Value ObjectsをDTOに配置するのは正しいとは思いません。値オブジェクトはドメインモデル内にあり、言及したDTOはモデルのインターフェイスを定義しています。私たちは通常、何かの内側から外の世界を切り離すためのインターフェイスを構築します。したがって、現在のケースでは、Valueオブジェクト（およびその他のモデル関連のもの）から外側の世界を分離するためにDTOを追加しました。その後、インターフェイスに値オブジェクトを追加するとクレイジーになります。

したがって、あなたはまだパターンアンチパターンであるため、この解決策を満たしていません。