境界付きコンテキストの境界を明確に定義する方法
1か月ほどDDDを読んで研究した後、私は自分のプロジェクトを開始することに決め、これらの制限されたコンテキストでDDDを作成しました>
- クライアント
- 製品
- 注文
- 課金
境界のある各コンテキストには、プレゼンテーション層、ドメイン層、永続層としてREST APIがあります。
これまでのところ、コードはスムーズに実行されていますが、モノリシックな世界から来ているため、私はまだ次のことを理解しようとしています：
- 新しいクライアントを作成したい場合、新しい請求書を発行したい場合、たとえば、国のアクセスリストなど、新しい注文を作成したい場合。私は：
a）各BCの国のリストを作成する
b）国BC-> APIを作成し、それを使用して利用可能な国のリストを取得する
c）サードパーティのAPIを使用し、各BCの腐敗防止層を介してデータをプルする
- 破損防止レイヤーまたはアダプターレイヤーを使用してサードパーティのAPIと統合する場合、ドメインモデルにどのデータを含める必要がありますか？たとえば、zendesk APIをクライアントBCと統合したい場合。ドメインにticketIDだけが必要ですか、それともクライアントBCでアクセスして使用するすべてのデータをZendeskから抽出する必要がありますか？
MVCアプリが実際にAPI（境界コンテキストのプレゼンテーションレイヤー）からデータを取得している場合、各BCの境界を明確に定義することは非常に困難です。それは、適切に設計されたBCが、追加のAPIを消費する必要なしに、単一のMVCコントローラーを提供することを意味しますか？
異なる境界のコンテキストが国の意味/目的を異なる方法で理解している場合は、国ごとに適切に異なるモデルを作成する必要があります。ただし、ISOコードと名前の参照データについてだけ言えば、都合のよい場所に保管し、すべての関係者がアクセスできるようにすることは、かなり公正で標準的なことだと思います。たとえば、データベース、構成ファイル、Webサービスなどです。
私もあなたのモデルを少し見たかったです。あなたがリストしたものは、会社の構造に応じて、1つの「境界のあるコンテキスト」内の「エンティティ」である可能性が非常に高くなります。 BCはしばしば「ユビキタス言語」間の自然な境界であることが多いため、さまざまな領域/部門/チームを中心に定義されることになります。したがって、たとえば、Sales/Products/Ordersの代わりに、BCはSales/Manufacturing/Warehousingのラインに沿っていると期待します。
それらの紀元前では、名詞に焦点を当てていません。ユースケースに焦点を当て、ユースケースを実行できる名詞のモデルを作成します。 「集約ルート」のメソッドは、ユースケースを実行し、関連するモデルに適切な変更を加えます。
また、各BCはまったく異なるシステムまたはアーキテクチャを使用する場合があることにも注意してください。特定のBCは「DDDソフトウェアコンポーネント」を使用するメリットがまったくない場合があり、それらのほとんどはおそらくそうではありません。 DDDは、規範的なソフトウェアコンポーネントについてではなく、ソフトウェアの設計プロセスについてです。ポイントは、会社の境界のあるコンテキストの理解、各コンテキストのユビキタス言語のマッピング、およびユビキタス言語を使用したそのコンテキストのコードのモデリングに焦点を当てることです。そうすれば、利害関係者とやり取りしてコードを参照するときに、彼らが理解しているビジネス用語で話しているように聞こえます。そして、同じ言葉が異なるBCで異なる意味を持つことを認識する。
DDDによってもたらされた特定のパターン（リポジトリ、特定のレイヤーなど）があり、目的を達成するためのものです。ただし、これらのパターンは、DDD内であっても、すべての場合に最適なパターンであるとは限りません。ちょうどDDDがすべてのプロジェクトの「その」答えではないように。あなたはあなたの分析が示唆することをしなければならないだけです。
あなたの質問から、あなたは限られた文脈を誤解していると思います。 blue book の第14章をもう一度読んでください。
一般的に答えようとする-2つの異なる境界コンテキスト間で概念を共有することに注意する必要があります。結局のところ、境界が存在する理由の一部は、ユビキタス言語が変化するためです。エンティティの同じデータ（および同じ表現）を両方のコンテキストで使用できると仮定するのは簡単ではありません-正しいかもしれませんが、間違っているかもしれませんが、外部にいる私たちにとって、アクセス権のない良い方法はありませんあなたのドメインの専門家に、裁判官に。
たとえば、クライアントドメインでは、「国」は居住または市民権に関連している可能性があります。請求では、為替レートに関連している可能性があります。それらのドメインのいくつかでは、関税などについて心配する必要があるかもしれません。
提起する必要がある2番目の質問は、どのモデルが「共有」データの記録簿であるかです。 「国」の場合、正しい答えはおそらくどれもないということです！地政学的トポロジーはモデルによって制御されません。
国が外国勢力に占領されている場合、ドメインモデルで何が起こると思われますか？
覚えておいてください。私たちの多くは、データ構造について考えることに慣れています。あるデータと別のデータの関係は何ですか。また、レポートを検討していて、必要なすべてのデータがソリューションによって収集されていることを確認しようとしている場合は、これは素晴らしいことです。しかし、ドメインモデルは構造だけではなく、変化についてのものです。その部分にも注意を向ける必要があります。また、データが変更をどのように制約するか（また、これらの制約が境界コンテキストごとにどのように変化するか）を十分に理解していることを確認してください。
この主題についての私の見方は、ビジネス能力マッピングまたはバリューチェーン分析のような他の同様の手法を使用して、 境界付きコンテキスト を定義することです。それは次のステップに帰着します：
- システムのより高いレベルの責任またはビジネス機能を定義します。それを行うための最良の方法は、企業がビジネス価値を獲得するために実行するステップを思い起こすことです。考えられる論理的な境界は、ビジネスサービス、または必要に応じて制限付きコンテキストです。
- 各サービスの詳細を調べます。
- 最初の2つのポイントとともに、サービス間の通信を特定します。
したがって、最初の焦点は、ビジネスの運用方法です。
いくつかの実用的なアドバイス：
- コンテキスト/サービス/その他の1つが他のコンテキストのデータを必要とする場合、おそらく境界が間違っています。
- コンテキスト通信の非常に望ましい方法はイベントベースです。これは、スケーラビリティと信頼性の鍵です。同期通信が必要な場合は、おそらく境界が間違っています。その上、同期通信はあなたのシステムを殺します。
- あなたのドメインはあなたが思っているよりも最終的に一貫性があります。みんなのように。すべてを100％一貫性のあるものにしようとしないでください。そこには実用的な意味はありません。
- コンテキストを調整する必要はありません。それらは自己完結型です。人間のように。
このアプローチにより、高度な自律性、保守性、信頼性のあるサービスが得られます。 例を確認する コンテキスト境界を定義することをお勧めします。
言及する概念（クライアント、製品、注文、請求）は、通常、単一のドメインモデルで表現されるため、境界コンテキストで表現されます。これらの概念を正しく理解していないことをお勧めします。