1か月ほどDDDを読んで研究した後、私は自分のプロジェクトを開始することに決め、これらの制限されたコンテキストでDDDを作成しました>
境界のある各コンテキストには、プレゼンテーション層、ドメイン層、永続層としてREST APIがあります。
これまでのところ、コードはスムーズに実行されていますが、モノリシックな世界から来ているため、私はまだ次のことを理解しようとしています:
a)各BCの国のリストを作成する
b)国BC-> APIを作成し、それを使用して利用可能な国のリストを取得する
c)サードパーティのAPIを使用し、各BCの腐敗防止層を介してデータをプルする
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番目の質問は、どのモデルが「共有」データの記録簿であるかです。 「国」の場合、正しい答えはおそらくどれもないということです!地政学的トポロジーはモデルによって制御されません。
国が外国勢力に占領されている場合、ドメインモデルで何が起こると思われますか?
覚えておいてください。私たちの多くは、データ構造について考えることに慣れています。あるデータと別のデータの関係は何ですか。また、レポートを検討していて、必要なすべてのデータがソリューションによって収集されていることを確認しようとしている場合は、これは素晴らしいことです。しかし、ドメインモデルは構造だけではなく、変化についてのものです。その部分にも注意を向ける必要があります。また、データが変更をどのように制約するか(また、これらの制約が境界コンテキストごとにどのように変化するか)を十分に理解していることを確認してください。
この主題についての私の見方は、ビジネス能力マッピングまたはバリューチェーン分析のような他の同様の手法を使用して、 境界付きコンテキスト を定義することです。それは次のステップに帰着します:
したがって、最初の焦点は、ビジネスの運用方法です。
いくつかの実用的なアドバイス:
このアプローチにより、高度な自律性、保守性、信頼性のあるサービスが得られます。 例を確認する コンテキスト境界を定義することをお勧めします。
言及する概念(クライアント、製品、注文、請求)は、通常、単一のドメインモデルで表現されるため、境界コンテキストで表現されます。これらの概念を正しく理解していないことをお勧めします。