a)ほとんどの場合、コア ドメインとジェネリック サブドメイン( GS ) には同じドメイン モデルの異なる部分が含まれていますか? それとも、各 GSが独自のドメイン モデルを定義しており、通常、コア ドメインで使用されるモデルとは異なりますか?
b) 前者の場合、両方が同じモデルを使用する理由は、 GSの主な目的がCore Domainに「サービスを提供する」ことであり、GSが「サービスを提供」できるのは、コア ドメインとGS (それぞれが独自のモデルを使用する場合、 GSとコア ドメインの間に変換レイヤーも必要になります)?
ありがとう
コア ドメイン、サポート サブドメイン、およびジェネリック サブドメインは、DDDの境界コンテキストの概念に基づいて進化します。
あなたの質問に答えるために、コアドメインはあなたのビジネスをユニークにし、競合他社よりも有利になるドメインです - あなたはそれを改善するためにほとんどの努力（開発者/お金）を費やします. ジェネリック サブドメインは、依然として重要なトピックを処理しますが、タスクを十分に処理する既存のソリューション (概念または再利用可能なコードのいずれか) を見つける可能性があります。
ジェネリック サブドメインは、別のドメインに取り組むため、別のモデルになります。
ジェネリック サブドメインは、日付/時刻 (ゾーン) の処理 ( 2、第 15 章)、持続性、ユーザー インターフェイス ツールキットからメール サーバーまたは完全な在庫管理システム ( 1、第 2 章) まで、あらゆるものを記述できます。一方、在庫管理ロジックは、在庫管理システムのベンダーのコア ドメインです。
詳細な情報は、Implementing Domain-Driven Designという本と、もちろん、Eric Evans による Domain-Driven Design を紹介する元の本にあります。
更新：（コメントを参照）
私の意見では、あらゆる種類のサブドメインを使用するコアドメインで最も重要な側面は、このトピックを抽象的なレベルで考えすぎないことです。ドメイン駆動設計の最大の課題は、ドメイン駆動設計ブックの戦略設計セクションのパターン/戦略に計画的または偶然に一致する良い例を見つけること であることにおそらく同意するでしょう。
さて、私の理解では、コア ドメインとジェネリック サブドメインの間の翻訳レイヤーの必要性は、単純に必要性から生じるものです。Chapter 15, Distillation of Domain-Driven Designでは、ジェネリック サブドメインの開発方法に関する 4 つのオプションが、それぞれの長所と短所とともに説明されています。
素晴らしい本からの引用が含まれているだけなので、議論を繰り返すことはしません. このプロジェクトにのみ使用されるカスタム調整され、適切に設計された社内ソリューションには、翻訳レイヤーは必要ないことにおそらく同意するでしょう。一方、商用またはオープンソースの既製のソリューションは、適切な意図を明らかにするインターフェイスなどがある場合、製品がどのように進化するかをほとんど制御できないため、抽象化が必要になる可能性が高くなります。
関連する他の 2 つの側面がありますが、サブドメインと混同しないでください。
境界付けられたコンテキストは、完全な定義による何らかの変換を必要とします。Bounded Contextごとに、Model in Contextがあります。Context Mapは、 Bounded Contexts とTranslation Mapとの関係と相互作用を文書化します。BoundedContextsのモデルを関連付けるさまざまな方法については、第 14 章モデルの整合性の維持( Anti-Corruption Layer、Open-Host Serviceなど) で説明しています。
一方、結合メカニズム(ドメイン駆動設計の第 15 章を参照) は、不要な混乱からコア ドメインを解放するために導入されたジェネリック サブドメインに似ています。Eric Evans はCohesive Mechanismsを軽量なフレームワークと説明していますが、実際にはCohesive MechanismとGeneric Subdomainsの違いはほとんど純粋ではないことを認めています。
私は日常的にこれを扱っていないので、それらのセクションをもう一度読まなければならなかったと言いたいので、許してください. さらに、私は DDD コミュニティの内側にいるわけではないので、これらの問題が今日異なって評価されているかどうかはわかりません。それらは今でも非常に有用であると思われ、この分野でより優れたツール セットに出会ったことがないので、それらはまだ有効であると思います。
これらの概念を理解したいという衝動は理解していますが、実際の理解は具体的な例を見ることによってのみ達成できます. 書籍で紹介されているものもあります。それらのどれも完璧であると主張されていません。大小を問わず、これらの複雑な問題の理解と評価は時間の経過とともに変化し、これが私の意見では DDD の魂です。