境界のあるコンテキストを表現する方法は？

Question

つまり、物理的にはコードで。命名、名前空間、フォルダー、アセンブリ、データベース/sの組織化。

境界のあるコンテキストはどのように相互作用する必要がありますか？

たとえば、クラシックを自由に使用してください eコマースビジネスドメイン.

Answer 1

私は「それは依存する」と言う

BCエンティティを同じデータベースにマッピングするだけで十分な場合があり、BCのデータベースが異なる場合があります。

IMO、eコマースは、完全なドメインというよりもBCのようなものかもしれません。

私は彼らが食品を販売する販売エージェント全体で少し時間を費やしました。

したがって、ドメインは「販売全体」であり、境界のあるコンテキストは、在庫、購入、販売、請求書、製品カタログ、eコマースでした（おそらく、間違った英語の言葉遣いをここで使用しています）

これらのBCはそれぞれ「製品」を知っていましたが、それらはすべて製品の異なる見方を持っていました。

たとえば、ベンダー情報、購入価格などを備えた製品エンティティが添付されている場合があります。

eコマースドメインの製品は顧客の観点からモデル化されますが、それを見る顧客に関連する情報、特定の価格などがあります。

eコマースBCは、複数のソースから製品情報を取得します。製品カタログと販売。基本情報が製品カタログからのものであり、顧客固有の価格は販売からです。

したがって、eコマースBCの製品リポジトリは、他のBC（私の場合は、おそらくWebまたはWCFのある種のサービスを介して）からコンテキストマッピングを行う可能性があります。

個人的には、これを別々のアセンブリとしてモデル化します。電子商取引モデルと販売モデルがあります。

私の電子商取引モデルのほとんどの情報は、外部ソースからのものであり、局所的に持続的ではありません。これらのオブジェクトはeコマースモデルが所有しているため、ショッピングカートのようなもののみが局所的に永続的です。

顧客が購入を完了しようとすると、ショッピングカートから予約注文を作成し、それを販売BCに渡します。直接サービスコールまたはメッセージキューを介して。

要するに、私は特定のBCの周りにシステムを構築する傾向があり、サービスを通じて他のBCとのみ相互作用する傾向があります。

多くの人々が同じアセンブリにBCを入れ、同じアプリなどから複数のBCを使用していることを知っています。しかし、特定の目的のためのアプリが複数のコンテキストについて知っておくべき理由は奇妙です。私はむしろ、1つのコンテキストのみを知り、必要なデータを他のアプリに渡すものを渡します。

Answer 2

私は確かにそれがすべて依存することに同意しますが、順守/するべき/するべきいくつかのガイドラインがあります。境界のあるコンテキストの目的は、まあ、境界です。適切に定義された契約（インターフェイス）を導入することにより、アプリケーションの一部で別の境界を分離します。

私はSOAのBCSのようなサービスを扱う傾向があります。私にとっては、理想的には物理的に個別のアプリケーション（OSプロセス/IIS Webサイト）であることを意味します。もちろん、バイナリも分離されています。 BC間のすべての通信は理想的には非同期です。現実の世界では、それはほとんど不可能ですが、少なくとも私は彼らが純粋な悪であるため、クロスBCトランザクションを許可していません。

それが役立つことを願っています。