3

このコードサンプルを見つけました。

https://code.google.com/p/ddd-cqrs-sample/

非常に完成度が高く、よく整理されているようです。「フレームワーク」ではなく、物事を行うための非常にきめ細かく明示的な方法を備えた単なるサンプル プロジェクトです。しかし、不完全です。そして、これはいくつかの疑問をもたらします。

彼らは質問に答えるのが上手です。https://groups.google.com/forum/#!forum/ddd-cqrs-sampleで Google グループを確認してください。

わかった。SALES BC に Client があり、CRM BC に Customer/Leads があるということです。私たちは皆、同じ「人」を指していることに同意すると思います。販売目標到達プロセスで、その人が見込み客として始まり、何かを購入して顧客になることで顧客になるとしましょう。

私の質問は、なぜ彼らは同じ「人」の3つの別々の表現を持っているのですか? 「共有カーネル集合体」のようなものではないでしょうか? そのようなものが存在するかどうかはわかりません。データベース クライアント/顧客/リードに同じ「もの」の 3 つのテーブルがあるのはちょっと気になります。さらに、この例では、BC 間の通信方法が明確ではありません (CRM は実装されていません)。私は彼らのドキュメントを読みましたが、それに関する貴重な手がかりは見つかりませんでした。

そのプロセスはどのようになりますか？注文を発送するために、このリード/顧客/クライアントに住所を追加する必要があるとしましょう。あなたならどちらを選びますか？Shipping BC の ShippingAddress だと思いますか。を指しているIDで？お客様？クライアント？住所を顧客に直接追加する必要がありますか? 例えばダイレクトメールの場合、配送とは関係ないので？

4

3 に答える 3

5

共有カーネルにより、CRM とセールス BC の間に非常に緊密な結合が導入されます。

ここに代替案があります..

CRM BCは顧客を所有しています。セールス BC で完全な顧客 AR を複製する必要は必ずしもありません。これにより、双方向の同期を処理する必要がなくなります。Sales BC の Client AR が CRM BC の Customer AR をその識別子で参照するようにし、特定の Client プロパティを Sales BC にカプセル化したままにすることができます。これにより、Sales BC と CRM BC の間に適合性または顧客とサプライヤーの関係が作成されます。ここで、Sales BC はダウンストリームであり、CRM BC はアップストリームです。CRM コンテキストは、おそらくオープン ホスト サービスを使用して、営業 BC が顧客 AR を利用できるようにします。

于 2013-07-29T08:09:36.667 に答える
4

通常、コンテキスト全体での再利用は推奨されません。まれに共有カーネルが役立つ場合がありますが、通常、ドメイン オブジェクト (およびその集合体) は、それぞれのコンテキストに対してローカルに保つ必要があります。そうしないと、密結合が導入され、境界付けられたコンテキストの主な利点の 1 つが失われます。それらは互いに独立して変化したり進化したりすることはできません。

于 2013-07-29T17:14:31.910 に答える