1、概述1.1领域的广义领域：领域(域)是由一个组织进行和包含的全部。 每个组织都有自己的业务范围和做法。 这个业务范围和其中开展的活动有各自的业务范围和工作方法。 这个业务范围和其中开展的活动就是领域。 mmdbq组织开发软件时，你面临的是这个组织的领域。
域可以表示集成业务系统，也可以表示其中的某个核心域或支持域。 在DDD中，一个域被分成几个子域，域模型在边界上下文中完成开发。 在开发域模型时，我们通常只关注这个业务系统的某些方面。
1.2子域是一个域更细分的划分，根据重要性和功能将域大致分为三类多个子域，分别为核心子域、支持子域和通用子域。 核心域是业务成功的主要驱动因素和主要竞争力，支持子域是支持核心域，公共子域是业务系统的共同部分。 域中可以有多个支持子域，并且应该只有一个核心域。 当然，除了核心域以外，没有其他子域也是可以的。
核心域是最重要的，开发核心域解决方案是重要的业务投资，应该给予核心域开发最高的优先级和最好的开发团队。 如果核心域中的一些功能可以与核心域分离，则可以将其作为模块与核心域分离。 这里的模块实际上是一个名为java的软件包，也可以理解为命名空间和文件夹。
1.3边界上下文边界上下文包含系统、APP应用程序、业务服务和一系列实现业务的复杂组件。
例如，如果在一个电子商务服务系统领域中放入一个库存系统和一个外部预测系统，则该领域可以有对应的三个边界上下文。 一个边界上下文可以包含在一个子域中，也可以包含在多个子域中。 例如，电子商务系统包括发票子域、订单子域等。
2、关于工作中如何使用子域和边界上下文子域，我们先来看一下下面的简单例子。 这是零售商在线销售产品的例子。
要在这一领域开展业务，零售商需要展示不同类型的产品，支持订单和支付，并安排物流。 在这个领域，零售商领域可以分为四个主要子域。 产品目录(Product Catalog )、订单(Order )、发票(Invoicing )、物流(Shiping )。 下图显示了一个包含子域和边界上下文的领域，上半部分显示了这个电子商务系统。
这看起来比较简单。 一个领域包含四个子域。 但是，考虑到一些额外的细节，上述例子变得复杂。 将清单系统和外部访问预测清单系统添加到上述系统中，如下图所示。
目前，这个零售商领域只包括三个物理系统，其中两个是内部系统。 这两个系统代表两个边界上下文。 因此，一些子系统承担了很多业务功能。
在上述电子商务系统的边界上下文中，可以找到多个隐式区域模型，这些区域模型被集成到一个软件模型中。 随着新功能添加到各个逻辑模型中，它们之间的复杂关系对每个模型都是一个障碍。 这些问题的原因通常是由于软件关注点不明确而引起的。
通过使用DDD战略设计工具，可以根据实际功能将这些交织模型划分为逻辑上分离的子域，从而在一定程度上降低系统的复杂性。 逻辑子域的边界由上图中的虚线表示。 不同的逻辑子域之间或不同的物理边界上下文之间有一条线，这意味着它们之间存在集成关系。
库存问题也是电子商务系统的重要问题之一，库存的各种货物储存多久比较合适呢？ 一个好方法是根据过去的销售趋势制定未来的库存计划，优化库存系统。
添加预测引擎意味着开发新的核心域。 如果这个新解决方案是核心域，开发团队将受益于周围的逻辑子域和组体系。 因此，在该核心域项目启动时，上图现有的集成体系对了解项目情况起着重要作用。
子域并不一定构建得很大，它包含很多功能。 在某些情况下，子域只能包含一个算法。 该算法可能对业务系统非常重要，但不包括在核心域中。 如果DDD实现正确，则此简单的子域可以以模块形式与核心域分开，不需要包含在沉重的子系统组件中。
在实施DDD时，致力于按照边界上下文中的领域模型所使用的每个术语进行上下文边界的区分。 这一局限性主要是语言层面的上下文边界，也是实现DDD的关键。
在上图中，在语言级别设计了什么类型的边界上下文呢？
在电子商务系统中，当我们谈论四个子域时，我们经常看到一些术语是不一致的。 像“顾客”，在看商品目录时，“顾客”被放在以前购买的情况、忠诚度、可购买的产品、折扣、物流方式这样的语境下。 订单时，“客户”上下文包括名称、产品发送地址、订单总额和一些支付术语。 在该电子系统中，“顾客”没有明确的定义。 在良好的上下文中，每个术语只代表一个领域的概念。
但是也不能保证库存系统的模型是完全明确的，使用的是不完全模糊的领域的语言。 例如，“库存品”的概念是将已经订购但不能销售的产品称为延期订购品； 储存在仓库中的产品称为积压。 等等。
从表面上看，可以得出库存系统比电子商务系统的DDD健康指数高的结论。 原因是库存系统的开发团队没有使用一个库存部件来表示所有的概念。 这是否确实也不确定，但可以肯定的是，库存模型比电子商务系统模型更容易集成。
一个企业的边界上下文并不是孤立的
存在的。不同子域之间的实线表示集成关系，这样表明不同的模型时需要协同工作的。集成的方式有很多种，将在上下文映射图中学到不同的集成方案。 3、将关注点放在核心域上下图是一个领域的抽象视图，它可以表示任何一个领域，但是仅仅表示在某个时刻，从某个角度看的业务模型。
核心域：它是整个业务领域的一部分，也是业务成功的主要促成因素。从战略层面上讲，企业应该在核心域上胜人一筹。在实施DDD的过程中，应该主要关注核心域。
**支撑子域：**有时，我们会创建或者购买某个限界上下文来支撑我们的业务。如果这样的上下文对应着业务的某些重要方面，但却是不核心，那么它便是一个支撑子域。创建支撑子域的原因在于它们专注于业务的某个方面。
**通用子域：**如果一个系统被用于整个业务系统，那么这个子域便是通用子域。
并不能说支撑子域和通用子域是不重要的，它们是重要的，只是我们对他们的要求并没有像核心域那么高。
4、现实世界中领域和子域领域中还同时存在问题空间（problem space）和解决方案空间(solution space)。在问题空间中，我们思考的是业务所面临的挑战，而在解决问题空间中，我们思考的是如何实现软件以解决这些业务挑战。
问题空间是领域的一部分，对问题空间的开发将会产生一个新的核心域。对问题空间的评估应该同时考虑已有子域和额外所需子域。因此，问题空间是核心域和其他子域的组合。问题空间中的子域通常随着项目的不同而不同，他们各自关注于当前的业务问题，这使得子域对于问题空间的评估非常有用。子域允许我们快速地浏览领域中的各个方面，这些对于解决特定的问题是必要的。
解决方案空间包括一个或多个限界上下文，即一组特定的软件模型。这是限界上下文中即是一个特定的解决方案，它通过软件的方式来实现解决方案。
为了澄清问题空间和解决方案空间的区别，来看个例子。
例如大型的ERP系统，我们可以将一个ERP系统想象成一个单一的限界上下文。由于ERP系统提供许多模块化的业务服务，将不同的模块看成不同的领域是有好处的，比如，可将库存模块和采购模块拆分成不同的逻辑子域，分别命名为库存子域和采购子域。
上图表示的是一个ERP系统的领域，也是上述抽象领域模板的一个实例。该企业计划开发一个特定的领域模型来降低成本，该模型可以为采购人员提供决策工具，这个新的核心域可以提高该企业的竞争优势。
在实施某个解决方案之前，我们需要对问题空间和解决方案空间进行评估。为了项目朝着正确的方向进行，需要先回答以下问题：
这个战略核心域的名字是什么，它的目标是什么？这个战略核心域中包含哪些概念？这个核心域的支撑子域和通用子域是什么？如何安排项目人员？你能组建一支合适的团队吗？在理解问题空间之后，来看看解决方案空间。对于问题空间的评估也是有益于理解解决方案空间的。解决方案空间在很大程度上受到现有系统和技术的影响。这里，我们应该根据分离的限界上下文仔细地思考，考虑以下问题：
有哪些软件资产是已经存在的，它们可以重用吗？哪些资产是需要创建的，或者从别处获得？这些资产是如何集成在一起的？还需要什么样的集成？假如已经有了现有资产和那些需要被创建的资产，我们还需要做什么？核心域和那些支撑项目的成功率如何？会不会由于其中一个失败而导致整个项目失败的可能性？在哪些地方我们使用了完全不同的术语？限界上下文之间在哪些地方存在概念重叠？这些重叠的概念在不同的限界上下文之间是如何映射和翻译的？哪些限界上下文包含了核心域的概念，其中使用了哪些战术模式？在上图中，用于捕获决策工具和算法的采购模型表示了核心域的解决方案。该领域模型将在最优获取上下文中实现，该上下文与最优获取核心域存在着一对一的关系。由于只对应一个子域，同时又拥有优秀的领域模型，这个最优获取上下文将会是业务领域中最好的限界上下文之一。
在上下文映射图中，将主要介绍通过集成上下文的方式来完成不同通用语言之间的映射。
5、理解限界上下文限界上下文是一个显式的边界，领域模型便存在这个边界之内。领域模型把通用语言表达成软件模型。创建边界的原因在于，每一个模型概念，包括它的属性和操作，在边界之内都具有特殊的含义，且每个概念的含义便是确定的。因此，限界上下文主要是一个语义上的边界，我们应该通过这一点来衡量对一个限界上下文的使用正确与否。
限界上下文并不旨在创建单一的项目资产，让我们来看下一个账户（Account）模型在银行上下文（Blanking Context）和文学上下文（Literary Context）中的不同，如下表：
在图中，光凭名字我们根本无法区分两个账户的意思。只有通过它们所在的限界上下文我们才能看出他们之间的区别。
这两个限界上下文可能不属于同一个领域，这里说明：上下文才是王道。
限界上下文不仅仅只包含模型一个限界上下文并不是只包含领域模型，诚然，模型是限界上下文的主要“公民”。但是，限界上下文并不只局限于容纳模型，它通常标定了一个系统、一个应用程序或者一种业务服务。有时，限界上下文所包含的内容可能比较少，比如，一个通用子域便可以只包含领域模型。
当模型驱动着数据库Schema的设计时，此时的数据库scheme也应该位于该模所处的上下文边界之内。
限界上下文主要用来封装通用语言和领域对象，但同时它也包含了那些为领域模型提供交互手段和辅助功能的内容。需要注意的是，对于架构中的每个组件，我们都应该将其放在适当的地方。
限界上下文的大小
限界上下文可以包含多少领域模型中的基础部件呢，比如，模块、聚合、领域事件和领域服务等。限界上下文应该足够大，以能够表达它所对应的整套通用语言。但不要将核心域之外的概念不应该包含在限界上下文中。如果有一个概念不属于你的通用语言，那么一开始你就不应该将其引入到模型中。
与技术组件保持一致
将限界上下文想成是技术组件并无大碍，只是需要注意：技术组件并不能定义限界上下文。来看一些构成和部署限界上下文的常见做法。
当使用IDEA时，一个限界上下文通常就是一个工程项目。在使用Java时，顶层包名通常表示限界上下文中顶层模块的名称。对于上文中提到的例子，我们可以采用以下方式来定义包名：
com.chunsoft.optimalpurchasing限界上下文的源代码结构可以根据职责做进一步分解。下面是一些二级包名：
com.chunsoft.optimalpurchasing.presentationcom.chunsoft.optimalpurchasing.applicationcom.chunsoft.optimalpurchasing.domain.model请注意，即便存在这种模块化的拆分，团队依然应该只工作在一个限界上下文中。