1

と境界付けられたコンテキストについて質問があります。

2 つの境界付けられたコンテキストがあるとします。最初のものでは、集約ルートは Web ページに広告を公開できる Customer です。私はそれが彼の振る舞いに当てはまると思います。彼は PublishAdvertisement() のメソッドを持っています。しかし、2 番目の境界付けられたコンテキストには、Advertisement が集約されています。これは、Advertisement が Customer に属しているという性質上、Customer プロパティを持っていることを意味します。

Customer と Advertisement はどちらも、システムとデータベースで一意です。

私の質問は次のとおりです。顧客からの広告の作成をファクトリまたは依存性注入に委任することをお勧めしますか?

編集：

回答ありがとうございます 情報不足で申し訳ありません。

依存性注入:

特定の状況を解決するための最良の方法は何だろうと思っていました。会社には広告テンプレートの在庫があります。テンプレートが在庫にあれば使用できますが、そうでない場合は誰かにレンタルされます。同社は、より多くの株式を保有する計画を持っています。顧客がこれらのテンプレートで広告を作成したい場合は、テンプレートを選択し、在庫があればすべて準備完了です。これをそのまま読んで、サービス（ドメイン）CheckAvailability（テンプレート）が必要であると想定しました。サービスの性質上、検証でいくつかの集計を使用し、データベースにクエリを実行するため、特定の集計には適合しません。将来、より多くの Stocks (他の会社から借りたもの、おそらく他の誰かのデータベース) が存在するようになると、依存性注入を使用して、実装を変更せずにこれらの Stocks をサービスに追加することを計画していました。

制限されたコンテキスト:

境界付けられたコンテキストとデータベースに関して。はい、1 つのデータベース オブジェクトと、同じデータベース オブジェクトを使用する 2 つのコンテキストがあります。Order には Customer への参照があり、Customer に属しているため、次のようになります。

Order() 顧客 顧客 (get; プライベート セット;)

///その他のプロパティとメソッド

これらのような 2 つのコンテキスト (Customer->Order___1:M) が同じデータベースに関連しているという意味で、リンク、ビデオ、本を介して追加情報をいただければ幸いです。ありがとうございました。

4

3 に答える 3

2

Customer と Advertisement はどちらも、システムとデータベースで一意です。

その場合、同じ DB オブジェクトを使用する 2 つの境界付けられたコンテキストでこれらの概念を持つことは問題です! 2 つの境界付けられたコンテキスト間の分離は強力なものであるため、同じ DB オブジェクトを変更することによって通信するべきではありません。

ですから、そこにはいくつかの大きな設計上の問題があると思います。まず、現実の問題に対応するモデルを作成して問題を解決し、ドメインの専門家と話し合ってください。

そして今、あなたの主な質問に答えるために：

ファクトリを介してエンティティを作成することをお勧めします。ファクトリは、エンティティを作成して必要なサービスを提供するための (潜在的に複雑な) メカニズムを隠します。ファクトリは、最初に DI を介してこれらのサービスを受け取り、インスタンス化中にそれらをエンティティに転送できます。

于 2015-12-16T08:36:48.227 に答える
1

絶対。

1 つはドメイン オブジェクトを関連付けることであり、もう 1 つはドメイン オブジェクトを操作することです。広告には関連付けられた顧客があり、顧客と広告はそれぞれのドメイン層 (つまり、少なくともリポジトリとサービス... ) で作成する必要があります。

広告が作成される場所で顧客が作成されることは望ましくないため、またその逆も同様であるため、これは適切な方法で懸念事項を分離しています。

単一責任の原則については、すでにご存じのことと思います。

于 2015-12-15T20:29:58.460 に答える
1

によって実施される顧客関連の不変条件は何Customer.PublishAdvertisement()ですか?

  • 何もない場合は、そのメソッドを Advertisement他の BC の集約ルートに移動して、おそらくコンストラクターにするAdvertisementFactoryか、構築ロジックが複雑な場合はに移動することをお勧めします。広告を作成する物理世界のユーザーが顧客であるからといって、その集約ルートにそのメソッドが必要であると自動的に暗示されるわけではありません。広告作成プロセスは、広告アプリケーション サービスをエントリ ポイントとして、広告 BC にとどまることができます。

  • 存在する場合、Customer は AdvertisementPublishedAdvertisement BC がサブスクライブするイベントを発行できます。ただし、「一貫性の境界として集約する」というグッド プラクティスに従う場合、顧客は広告とすぐに一貫性を保つことができないことに注意してください。Advertisement永続化されるため、他のクライアントに表示されます。

    通常、新しい AR を作成する場合は問題になりませんがCustomer、不変条件をチェックして を作成することを決定したの状態はAdvertisement 変更される可能性があり、その間に不変条件に違反する可能性があることに注意してAdvertisementください。

    明らかに、2 つの BC が共通のデータベースを共有していることを考えると (@theDmi が指摘したように、これはおそらく良い考えではありません)、そのルールを破ってトランザクションを 2 つの集計にまたがるようにすることができます。新しい Advertisement を保持するだけで、同時にアクセスできる可能性のある Advertisement を変更しない場合は、必ずしもそれほど悪くはありません。

依存性注入に関する限り、ここで接続が見えません。注入される依存性は何ですか?

于 2015-12-16T10:30:36.807 に答える