1.限界上下文（bounded context）：

就是给每个系统划分出一个边界，比如一个电商系统，库存、订单、价格、支付都是一个限界上下文。


2. 通用语言：

	例如：订单系统有一个customer对应的是在订单这个上下文里指的是下订单的人，采购系统有一个cunstomer指的是在采购这个限定上下文里采购的人，同样是customer在不同的系统（限定上下文）对应的含义不同
在不同的系统对应的限界上下文，定义出一组名词（一堆类），代表了这个限界上下文里的通用语言，
只有这个限界上下文的工程师，会按照同样的一批通用语言来理解所有的名词。
如果跨限界上下文，理解可能不一样


3. 子域

实际上就是限界上下文，就是一个个子系统，又分为核心子域（核心系统）、
支撑域（支撑性功能子系统，非核心模块，如评论系统）、通用子域（一些通用的系统，如权限、hr，oa系统等）
逻辑子域（比如没有独立的功能模块，没有独立的数据库可，如比对系统）


4. 上下文映射context mapping

实际上是子系统集成（接口集成）就是各个系统如何通过接口进行集成，
即需要把别的系统的通用语言转化成自己系统的通用语言，子系统的集成关系


5. 实体

和值对象的区别，有唯一标识


6. 值对象

多个属性和对象的组合，没有唯一标识


7. 聚合

8.领域事件


9. 战略设计

 子系统的拆分和集成，概要设计部分，架构图部分


10. 战术设计

      详细设计部分，设计各个类和核心方法，子系统的流程和时序图之类的。


11. 上下文关系

定义不同子域子系统之间的上下文关系，集成关系，也决定了他们的继承方式、（rpc，rest，mq）

U：一般U是上游，upstream，就是服务的提供者
D：一般是下游，downstream，服务的调用者
调用谁谁就是下游，谁提供服务谁就是U

· 合作关系（Partnership）：两个上下文强耦合在一起，基本上就是比如做一个需求吧，多人一起做，
大家都是为了一个需求设计自己服务的接口，基本上服务之间以及接口之间都是特定耦合，强行耦合的，
为了完成一个完整的需求，难以分开，这种一般是紧密协作的团队内部或者多个团队，都是做一个项目和需求，
常常是这种模式
 
· 共享内核（Shared Kernel）：两个上下文中间一起商量定义一个通用的领域模型，大家一起用，
维护一个独立的通用工程，一般团队内部的不同子域会用这种方式，不同人负责不同的服务，
但是抽象一些通用模型出来
 
· 客户方-供应方开发（Customer-Supplier Development）：上下文之间互相有商有量的进行通用语言的设计，
比如接口提供方设计接口和模型，会问问调用方，调用方也会提自己的需求给提供方，
这种的话，一般都是跟合作关系一起用的，有时候大家会这样商量协作，有组织的协作，当你需要做某个事儿的时候，
需要团队内部或者其他团队协作，去调用人家的接口，人家可能没有，你可以提个需求，大家商量一下
 
· 遵奉者（Conformist）：设计通用语言的时候，谁也别商量，调用的时候互相了解一下，直接调用，
这种情况我觉得是很多的，就是有个服务按自己的想法暴露一些接口出来，你需要的时候直接去调用就行了，
别多啰嗦，团队内部或者外部都有可能的，就是人家不会配合你的，你就调用
 
· 防腐层（Anticorruption Layer）：对其他的服务进行接口调用的时候，要把接口返回给你的东西做一下转换，
转换为你内部的实体，避免人家接口改变，你这里就变，这是防腐的一个层
 
· 开放主机服务（Open Host Service）和发布语言（Published Language）：这一般是大公司内部，
有那种中心之间的调用交互，暴露开放接口，定义一种协议/语言，一般都是RESTful API，
或者是第三方公司开放给你的接口
 
· 大泥球（Big Ball of Mud）：搞的一塌糊涂
 
· 独立路线（SeparateWay）：没关系

ddd建模三个步骤：

 划分子域---> 子域的集成关系 ---> 实体建模