つまり、物理的に、コードで。ネーミング、名前空間、フォルダー、アセンブリ、データベースの編成。
制限されたコンテキストはどのように相互作用する必要がありますか?
たとえば、従来のeコマースビジネスドメインを自由に使用できます。
つまり、物理的に、コードで。ネーミング、名前空間、フォルダー、アセンブリ、データベースの編成。
制限されたコンテキストはどのように相互作用する必要がありますか?
たとえば、従来のeコマースビジネスドメインを自由に使用できます。
私は「それは依存する」と言うでしょう
BCエンティティを同じデータベースにマップするだけで十分な場合もあれば、BCごとに異なるデータベースを使用する場合もあります。
IMO、eコマースは完全なドメインというよりはBCのようなものかもしれません。
私は彼らが食品を販売する販売代理店全体で少し多くの時間を過ごしました。
つまり、ドメインは「販売全体」であり、境界のあるコンテキストは、在庫、購入、販売、請求、製品カタログ、およびeコマースでした(ここでは間違った英語の表現を使用している可能性があります)
これらのBCはそれぞれ「製品」について知っていましたが、製品に対する見方はそれぞれ異なっていました。
たとえば、購入には、ベンダー情報、購入価格などが添付された製品エンティティが含まれる場合があります。
eコマースドメインの製品は顧客の観点からモデル化されますが、それを表示する顧客に関連する情報、特定の価格などが含まれます。
eコマースBCは、複数のソースから製品情報を取得します。製品カタログと販売。ここで、基本情報は製品カタログからのものであり、顧客固有の価格は販売からのものです。
したがって、eコマースBCの製品リポジトリは、他のBCから(ある種のサービス、私の場合はWebまたはwcfを介して)コンテキストマッピングを実行して、eコマース製品エンティティを構築する可能性があります)
個人的には、これを別々のアセンブリとしてモデル化します。eコマースモデルと販売モデルがあります。
私のeコマースモデルの情報のほとんどは外部ソースからのものであり、ローカルで永続的ではありません。これらのオブジェクトはeコマースモデルによって所有されているため、ショッピングカートのようなものだけがローカルに永続的です。
顧客が購入を完了しようとすると、私はショッピングカートから予約注文を作成し、それを販売BCに渡します。直接サービスコールまたはメッセージキューを介して。
つまり、私は特定のBCを中心にシステムを構築し、サービスを介して他のBCとのみ対話する傾向があります。
多くの人が自分のBCを同じアセンブリに入れ、同じアプリなどから複数のBCを使用していることを知っています。しかし、特定の目的のアプリが複数のコンテキストについて知っている必要があるのは奇妙なことです。むしろ、1つのコンテキストについてのみ通知してから、必要なデータを他のアプリに渡したいと思います。
私は確かにそれがすべて依存することに同意しますが、従うことができる/従うべきいくつかのガイドラインがあります。境界付きコンテキストの目的は、まあ、境界です。明確に定義されたコントラクト(インターフェース)を導入することにより、アプリケーションの一部を別のアプリケーションから分離する境界。
私はBCをSOAのサービスのように扱う傾向があります。私にとっては、理想的にはそれらが物理的に別個のアプリケーション(OSプロセス/ IISWebサイト)であることを意味します。もちろん、バイナリも分離されています。BC間のすべての通信は、理想的には非同期です。現実の世界ではそれはほとんど不可能ですが、少なくとも私はそれらが純粋な悪であるため、クロスBCトランザクションを許可しません。
お役に立てば幸いです。