DDD境界コンテキストとドメイン？
私は10のデータベーステーブル（集約、エンティティ/値オブジェクト）を使用して比較的複雑なアプリケーションで作業し、DDDを適用しています。この時点では、基本的にDDD-Liteのように見え、アプリケーション/ドメインサービス、ドメインモデル（エンティティ、値オブジェクト）、およびリポジトリがあることを意味します。
私は本を手に取りました Implementing DDD と彼が最初に言及していることは、DDDを開始するときによくある最初の間違いとして、DDD-LiteとBounded ContextsとDomain Eventsが欠けていることです。
現在、私はドメインモデルを集約関係で整理し、名前空間を使用してそれを実証しようとしました。
（まだ）ドメインモデルプロジェクトを個別の境界付きコンテキストに分離することに関連する利点/欠点を確認できていません。おそらくそれは後で明らかになるでしょうが、境界コンテキスト（およびサブドメインなどが結びついている場合は、サブドメインなど）に関する実際のフィードバックが欲しいです。
いくつかの異なる部門を持つ会社を考えてみましょう。
- ソフトウェア開発
- 人事
- 経理
これらすべてのビジネス領域を表現的に表現できるユーザーモデルを思いつくことができますか？それぞれのUserエンティティがどのように見えるかを考えてください。おそらく3つの異なるエンティティに分割されています。
- 開発者
- 従業員
- 受取人
各コンテキストでユーザーをインスタンス化する作業はかなり異なります。おそらくそれはこのようなものです：
- 新しい従業員（ssn、name、joindate、dateofbirth、gender）
- 新しい開発者（従業員、ワークステーション、資格情報）
- 新しい受取人（従業員、役割）
例をすみません、適切なドメインモデルを参照せずに正確に説明することは困難です
単純な実装を使用し、単一のユーザーエンティティを使用した場合、場所全体でユーザーを完全に表すことができなかったため、ゲッターとセッターでいっぱいの貧血データモデルになります。
ビジネスには明確な境界があるため、そのようにモデル化すると便利です。ログインしているユーザーと給与システムのユーザーとゲームをプレイしているユーザーは、同じグランドシステムの一部であっても、まったく異なります。
別の見方をすると、非常に軽量でシステムの他の部分から独立した開発者管理コードを作成できます。心配する手荷物が少なく、より正確なタイプを使用できます。これは、最終的に独自のアプリケーションに抽出される可能性がある、より小さなサブシステムを構築するためのステップです。
別の例を挙げましょう。 eコマースシステムがあるとします。そこに製品がありますが、製品は少なくとも2つの異なるドメインの一部になります。
- 製品の説明とすべての属性を保持する製品カタログ
- 製品在庫レベルがある在庫
両方のドメインに1つの境界コンテキストがある場合、ソリューションを相互参照し始めるため、ソリューションはすぐに大きな泥の玉になる可能性があります。最後に、2つのドメインはもうありません。あなたの製品在庫は製品カタログ参照で台無しにされ、逆もまた同様です。これの結果として、これが必要とされていないことを完全に理解していても、別のドメインに触れずに1つのドメインを変更することはできません。モデルは相互に依存し、密結合し、悪い方法で依存します-実装に依存しています。
ただし、2つの境界のあるコンテキストがある場合、1つのドメインで行ったすべての変更は、通信チャネルを明確に維持してもすぐには他のドメインに影響しません。これは、データの複製が必要であることを意味しますが、これは、疎結合コンポーネントベースのアプリケーションに対して支払うコストが最小です。ドメインは、ドメインイベントを使用して互いに通信できます。 SOAベースのアプリケーションを最初に用意する予定がない場合でも、ドメインイベントのトランスポートを変更するだけなので、比較的少ない労力で必要なときにそのレベルにスケールアップできます。 、アイデアをそのまま残します。
更新：エリック・エバンスからのスキルスキルに関する優れたスキルキャストがあります。いくつかの盲人が彼らの視点から象を説明するとき、彼は古い物語のアナロジーを与えます。それぞれの人間は象の一部にしか触れることができないので、彼らはそれを「木」、「壁」、「ヘビ」、「ロープ」と表現します。そして、それらの男性のそれぞれは、彼らの文脈の中で正しいです。境界のあるコンテキストは、ユビキタス言語が存在する場所です。文脈の外では、これらの用語は完全に異なる意味を持つかもしれませんが、文脈の中で、言語は複数のドメインで同じです。グレッグ・ヤングは、最も重要で基本的な概念がそこで説明されているので、第11章からブルーブックを読むことを強く勧めます。本の冒頭で戦術パターンに焦点を当てているため、この「DDD-light」アプローチは非常に一般的です。第8章のどこかで本を読むのをやめ、主要なものを見逃すと、後半にいくぶん埋め込まれます。