「シャーロットのトラブル」にはそのような筋書きがあります。シャーロットは中学校のクラスに行きました。夢の中で自分自身を見つけたとき、彼は古典的なセリフを言っている皮肉と皮肉であった彼の先生を見ました。それでも私をいじめさせますか？」これが彼の夢であり、彼の「領域」であり、彼がこの夢の「王」であるため、彼はそのような「人」の言葉を言うことができます。
次に、DDDにはドメインの概念もあり、チームの学生は、担当するドメインの「王」でもあります。ドメインを通じて、他の2つの概念、つまりサブドメインと境界テキストを紹介します。それで、今日の記事では、彼らの話について話しましょう。
1.フィールド
DDDの意味は「ドメイン駆動設計」なので、ドメイン（ドメイン）とは何ですか？
広い意味で、ドメインは組織が行うことであり、ドメインに含まれるすべてのものです。言い換えれば、会社または組織、その事業範囲、およびその中で実行される活動。
上記の定義は少しぎくしゃくしているかもしれないので、例として非常に人気のある「斗羅ダル」を取り上げましょう。タンサンはキリングゴッドドメインとブルーシルバードメインを取得しました。そして、ドメインの力を発揮した後、ドメイン内での自分の強さは大幅に増加し、相手の強さは大幅に弱まります。
その場合、会社は同じです。例として李寧とアリを取り上げましょう。スポーツウェアの分野では、李寧はアリよりもはるかに強力ですが、eコマースとインターネットの分野では、アリは李寧よりも強力です。つまり、ドメインという言葉の概念を説明するために、それは、あなたが実行し、アクティブで、得意なサークルです。
「ドメイン」という言葉の意味は多様であり、ビジネスシステム全体を表すだけでなく、特定の「コアドメイン」または「サポートサブドメイン」を表すこともできます。
「ドメインモデル」には「ドメイン」という言葉が含まれているので、 「聖闘士星矢」の聖闘士星矢のように、ビジネスシステム全体で単一の、完全で、まとまりのある、完全に機能するモデルを作成する必要があると考えるかもしれません。 、それは完全で、まとまりがあり、用途が広く、強力です。
次に、逆に、DDDでは、ドメインがいくつかのサブドメインに分割され、ドメインモデルが制限されたコンテキストで開発されます。実際、ドメインモデルを開発するとき、私たちは通常、ビジネスシステムの1つの側面、つまりサブドメインのみに焦点を合わせます。ソフトウェアシステム自体の複雑さに関係なく、ほとんどすべてのソフトウェアドメインには複数のサブドメインが含まれています。
2.サブドメイン
さまざまなタイプに応じて、サブドメインはコアドメイン、サポートサブドメイン、および一般サブドメインに分割できます。例として音楽のウェブサイトまたはアプリを取り上げます（著作権の問題を除き、すべてのデジタル音楽の主要な音楽のウェブサイトを平等に再生できると仮定します）、それは一般的に多くの機能を含み、音楽の好みの推奨、メンバーシップと許可、およびプロモーションにのみ焦点を当てています関数の3つの部分、次にこれらの3つの部分のサブドメインタイプの分割は次のとおりです。
【説明】
- それなら、音楽のウェブサイトやアプリを目立たせて一般の人に愛してもらいたいのであれば、音楽の好みのおすすめが中心的な能力になります。私はいくつかの曲を聴いたことがありますが、後でどの曲を聴くかはわかりませんが、ウェブサイトが私に勧めてくれました。曲は特に私の音楽の好みに合っているので、ユーザーは当然ここに来て曲を聴くことを好みます。したがって、**「音楽の好みの推奨」がコアドメイン**です。
- 実際、Webサイトの各機能は、アクセス許可とアクセス許可を持つ機能とともに多かれ少なかれ使用されるため、**「メンバーシップとアクセス許可」は一般的なサブドメイン**です。
- 而“促销活动”这部分也属于业务能力的一部分，但是并没有核心域那么重要，“促销活动”便是支撑子域。
2.1> 核心域
它是整个业务领域的一部分，也是业务成功的主要促成因素。从战略层面上讲，企业应该在核心域上胜人一筹。我们应该给予核心域最高的优先级、最资深的领域专家和最优秀的开发团队。在实施DDD的过程中，你将主要关注于核心域。
2.2> 支撑子域
如果某个限界上下文对应着业务的某些重要方面，但却不是核心，那么它便是一个支撑子域。创建支撑子域的原因在于它们专注于业务的某个方面。
2.3> 通用子域
如果一个子域被用于整个业务系统，那么这个子域便是通用子域。
三、限界上下文
运用限界上下文（BoundedContext）的战略设计模式来分离领域模型。一个领域被分为若干个子域，领域模型在限界上下文中完成开发。
在实施DDD的时候，我们要保证每一个术语应该仅表示一种领域概念，即：将用到的每一个术语进行限界划分。这种基于语言层面上的上下文边界划分，也是实现DDD的关键。如下所示，同样的“售卖”一词在不同的上下文中含义都是不一样的：
限界上下文是一个显式的边界，领域模型便存在于这个边界之内。领域模型把通用语言表达成软件模型。创建边界的原因在于，每个模型概念，包括它的属性和操作，在边界内都具有特殊的含义。
上面我们介绍限界上下文的时候，一直再提边界的问题，边界真的这么重要？没有边界，不是一样不影响我们项目的开发迭代吗？ 其实不然，在我们试图创建一个“大而全”的软件模型的时候，要使所有人都对某个概念的定义达成一致几乎不可能。因此，最好的方法是去正视这种不同，然后使用限界上下文对领域模型进行分离。可以举个例子，在广场上有一群人要商量去哪里，大家各抒己见，无法达成一致。
那怎么办呢？大家谁都不让步。分析原因，广场上的这群人，彼此之间又都是陌生的，那么陌生人也不会轻易的迁就对方，那么我们以家庭进行分组（建立边界），由一家人（即：在同一限界上下文中）内部去商量要去哪里，确定一致性建议。
1
由上面的例子我们可以看到，将不同的家庭分界开来，由于一家人是有血缘关系的，所以更容易达成一致。而在DDD中的这种“一家人”，就属于限界上下文，它把一个领域（类比：广场）划分为多个限界上下文，在限界上下文中进行领域建模，同时，这样更容易对某个概念的定义达成一致，建立专属这个限界上下文的领域语言。
四、战略设计的重要性
DDD是分为两大部分内容的：宏观上的——战略设计和微观上的——战术设计。而在上面我们介绍的“领域”、“子域”和“限界上下文”其实都属于战略设计。那么在实施DDD的过程中，我们也需要遵守先执行战略设计，再执行战术设计的方式。那么，战略设计为什么这么重要呢？
其实一提到战略和战术，大部分同学的第一反应应该是在战场上高频出现的词汇，那么我们就以战场来做解释。下面是辽沈战役攻打锦州的作战部署图：
从上面的图中我们可以看到，分为了“2C”、“7D”、“8D”、“8C”等作战部队，并且针对每个部队都标注着要攻打的位置和路线。在这张图里，并没有标注用什么枪、用什么炮、用什么手榴弹、多少医护人员……也就是说，不包含打仗的具体细节（战术模式），只在宏观上（战略模式）划分的队伍和攻打方向。如果没有这个宏观的作战图，那么部队将会一盘散沙，各自为战，没有任何配合可言了。这个跟我们DDD中的战略模式是类似的。如下是对应关系：
- 领域——>攻打锦城
- 子域——>部队
- 核心域——>主力部队，比如：8D
- 支撑域——>其他非主力部队
- 通用域——>通信部队，医疗部队，炊事班
- 限界上下文——>某部队负责攻打的区域
通过上面针对战争的例子来看，战略的重要性远不亚于战术，就像人们常常说的那句话——“方向不对，努力白废！”，而战略设计就是DDD中的方向。
五、问题空间&解决方案空间
领域中还同时存在问题空间和解决方案空间。它们的含义如下所示：
软件开发过程，本质上可以看作是问题空间到解决方案空间的一个映射转化。
5.1> 问题空间
在实际项目中，我们可以针对如下问题，对问题空间进行评估：
- 这个核心域的名字是什么？目标是什么？包含哪些概念？
- 支撑子域和通用子域是什么？
- 如何安排项目人员？能否组件一只合适的团队？
5.2> 解决方案空间
解决方案空间在很大程度上受到现有系统和技术的影响。在实际项目中，我们可以针对如下问题，对解决方案空间进行评估：
- 有哪些软件资产是存在的？是否可以重用？是否需要创建？是否可以从别的地方获得到？
- 这些资产是如何集成起来的？需要如何集成？
- 假设资产都已经ok了，我们还需要做什么？
- コアドメインとサポートプロジェクトの成功の確率はどれくらいですか？それらの1つが失敗したために、それらすべてを失う可能性はありますか？まったく異なる用語をどこで使用しますか？
- 境界コンテキスト間の概念的な重複はどこにありますか？これらの重複する概念は、異なる境界のあるコンテキスト間でどのようにマッピングおよび変換されますか？
- どの境界コンテキストにコアドメインの概念が含まれ、[Evans]のどの戦術パターンが使用されていますか？
より興味深いDDD記事については、「Java Muse」\（^ o ^）/〜「乾物共有、毎週更新」に注意してください。