领域

一个业务范围及其中所进行的各种活动。

核心域

是领域中最重要的一块，可以把它看作是人体中的心脏。

子域

理解子域的概念，必须和核心域对应起来，子域也是领域的一部分，只不过它的重要性没有核心域那么大，它们之间的关系，你可以看作是人体器官中，心脏和其他器官的关系，在《实现领域驱动设计》中，作者把子域拆分成了支撑子域（Generic Subdomain）和通用子域（Common Subdomain）。对于领域来说，除了核心域，用来支撑核心域的子域，就可以称之为支撑子域，在整个领域中，可以被公用的子域，称之为通用子域，通用子域还有一个理解是，在某一个业务领域中，它可能是被看作是通用领域，但是在另外一个业务领域中，它可能就被看作是核心域了。

通用语言

统一语言是提炼领域知识的产出物，获得统一语言就是需求分析的过程，也是团队中各个角色就系统目标、范围与具体功能达成一致的过程。

使用统一语言可以帮助我们将参与讨论的客户、领域专家与开发团队拉到同一个维度空间进行讨论。一旦确定了统一语言，无论是与领域专家的讨论，还是最终的实现代码，都可以通过使用相同的术语，清晰准确地定义领域知识。重要的是，当我们建立了符合整个团队皆认同的一套统一语言后，就可以在此基础上寻找正确的领域概念，为建立领域模型提供重要参考。

限界上下文

限界上下文是一个语义上的边界，在边界内，通用语言中的所有术语和词组都有特定的含义。在很多情况下，在不同模型中存在名字相同或相近的对象，但是它们的意义却不同。当模型被一个显示的边界包围时，其中每个概念的含义都是明确的。比如用户，可能是C端的产品使用者，可能是B端的商家，可能是平台自己的运营，语义是不明确的。在商家管理的限界上下文，用户就是商家，含义是明确的。

上下文映射

上下文映射图就通过画图的方式展示N（N>=2）个上下文之间的映射关系。
上下文有如下组织和集成模式的定义：
合作关系：需要一起协调开放计划和集成管理。
共享内核：共享模型和代码
客户方-供应方：两个团队处于上下游关系，上游团队需要顾及下游团队的需求
遵奉者：两个团队处于上下游关系，上游团队没有顾及下游团队的需求，下游团队只能盲目地使用上游团队的模型。
防腐层 : 在自己的模型和他方模型之间进行翻译转换
开放主机服务：定义一种协议，通过协议来访问服务
发布语言：在两个限界上下文之间翻译模型需要一种共享的公用的语言。发布语言通常和开放主机服务一起用
大泥球：当我们检查已有系统时，经常会发现系统中存在混杂在一起的模型，它们之间的边界是非常模糊的。此时你应该为整个系统绘制一个边界，然后将其归纳在大泥球之列。

参考：https://blog.csdn.net/jspyth/article/details/83216767

关联

实体（entity）

许多对象不是由它们的属性来定义，而是通过一系列的连续性（continuity）和标识（identity）来从根本上定义的。只要一个对象在生命周期中能够保持连续性，并且独立于它的属性（即使这些属性对系统用户非常重要），那它就是一个实体。

值对象（value-object）

当你只关心某个对象的属性时，该对象便可作为一个值对象。为其添加有意义的属性，并赋予它相应的行为。我们需要将值对象看成不变对象，不要给它任何身份标识，还应该尽量避免像实体对象一样的复杂性。

服务（service）

领域中的服务表示一个无状态的操作,它用于实现特定于某个领域的任务。当领域中的某个操作过程或转换过程不是实体或值对象的职责时，此时我们便成该将该操作放在一个单独的接口中，即领域服务。请确保该领域服务和通用语言是一致的；并且保证它是无状态的。

参考：https://www.jianshu.com/p/da51d16dbdc4

领域事件

模块（module）

模块应该包含一組具有高内聚性的概念集合.这样做的好处是可以在不同的模块之间实现松耦合。否则，我们应该修改模型以重新划分这些概念。……由于模块名是UL的一部分，模块名应该反映出它们在领域中的概念。

问题空间

解决方案空间

参考文章

《实现领域驱动设计》