DDDバウンドコンテキストとドメイン？

私は、数十のデータベーステーブル（集計、エンティティ/値オブジェクト）を使用する比較的複雑なアプリケーションで作業し、DDDを適用しています。この時点では、基本的にDDD-Liteのように見えます。つまり、アプリケーション/ドメインサービス、ドメインモデル（エンティティ、値オブジェクト）、およびリポジトリがあります。

私はDDDの実装という本を取り上げましたが、彼が最初に言及しているのは、DDDを開始するときによくある最初のミスとして、DDD-Liteおよびバウンドコンテキストとドメインイベントが欠落していることです。

現在、集計リレーションシップによってドメインモデルを整理し、ネームスペースを使用してそれを実証しようとしました。

ドメインモデルプロジェクトを個別のバウンドコンテキストに（まだ）分離することに関連する利点/欠点が見当たりません。おそらくそれは後で明らかになるかもしれませんが、バウンドコンテキスト（およびサブドメインなどが結び付けられている場合は、サブドメインなど）に関する実際のフィードバックをお願いします。

いくつかの異なる部門がある会社を考えてみましょう。

• ソフトウェア開発
• 人事
• 経理

これらすべてのビジネス分野を表現できるユーザーモデルを思いつくことができますか？各ユーザーエンティティがどのように見えるかを考えます。おそらく、3つの異なるエンティティに分割されています。

• 開発者
• 社員
• 受取人

各コンテキストでユーザーをインスタンス化する作業はかなり異なります。おそらく次のようなものです：

• new Employee（ssn、name、joindate、dateofbirth、gender）
• 新しい開発者（従業員、ワークステーション、資格情報）
• 新しい受取人（従業員、役割）

例を挙げてください。適切なドメインモデルを参照せずに正確に説明することは困難です

素朴な実装を使用し、単一のユーザーエンティティを使用した場合、ユーザー全体を完全に表すことができなかったため、最終的にはゲッターとセッターでいっぱいの貧弱なデータモデルになります。

ビジネスには明確な境界線があるため、そのようにモデル化することは有用です。ログインしているユーザーと給与システムのユーザーとゲームをプレイしているユーザーは、同じグランドシステムに属していても、すべて大きく異なります。

別の方法で考える-開発者管理コードを作成して、非常に軽量で、システムの他の部分から独立できるようになりました。心配する手荷物が少なく、より正確なタイプを使用できます。これは、最終的に独自のアプリケーションに抽出される可能性のある小さなサブシステムを構築するためのステップです。

別の例を挙げます。いくつかのeコマースシステムがあるとします。そこに製品がありますが、製品は少なくとも2つの異なるドメインの一部になります。

• 製品の説明とすべての属性を保持する製品カタログ
• 在庫、製品在庫レベルがある場合

両方のドメインに1つの境界コンテキストがある場合、ソリューションは相互参照を開始するため、すぐに大きな泥の塊になります。最後に、2つのドメインはもうありません。あなたの製品在庫は製品カタログ参照で損なわれ、その逆も同様です。この結果、必要ではないことを完全に認識していても、別のドメインに触れることなく1つのドメインを変更することはできません。モデルは相互に依存し、密結合し、悪い方法で依存関係になります-実装に依存します。

ただし、2つの境界コンテキストがある場合、通信チャネルを明確にするとすぐに、1つのドメインで行ったすべての変更が他のドメインに影響を与えることはありません。これは、データの複製が必要であることを意味しますが、これは、疎結合コンポーネントベースのアプリケーションの最低コストです。ドメインは、ドメインイベントを使用して互いに通信できます。初めにSOAベースのアプリケーションを使用する予定がない場合でも、ドメインイベントのトランスポートを変更するだけで、アイデアをそのままにしておくため、比較的少ない労力で必要なときにそのレベルにスケールアップできます。

更新：Eric EvansによるSkillsMatterの優れたスキルキャストがあります。いくつかの盲人が象を彼らの観点から説明するとき、彼は古い物語のアナロジーを与えます。各人は象の一部にしか触れることができないので、彼らはそれを「木」、「壁」、「蛇」、「ロープ」と表現します。そして、それらの人のそれぞれは、彼らの文脈の中で正しいです。境界のあるコンテキストは、ユビキタス言語が存在する場所です。コンテキスト外では、これらの用語の意味はまったく異なる場合がありますが、コンテキスト内では、言語は複数のドメインで同じです。グレッグヤングは、最も重要で基本的な概念がそこで説明されているため、第11章から青い本を読み始めることを強く提案します。本の冒頭で戦術的なパターンに焦点を当てているため、この「DDD-light」アプローチは非常に一般的です。