领域驱动设计-1
微服务近年来有很快的发展，很多公司也通过拆分单体架构为微服务，获得了更好的可扩展性和弹性。而在拆分微服务的过程中，常常会遇到服务拆分粒度的问题。
确定服务的粒度，其实也就是确定业务的边界，而领域驱动设计（Domain Driven Design）的思想便是通过定义领域模型，从而确定业务边界。
这个思想最早来自于2003年 Eric Evans编写的《Domain-Driven Design –Tackling Complexity in the Heart of Software》一书。
领域
一个边界之内要解决的业务域
子领域
领域的进一步划分，对应更小的业务范围
核心域
产品的核心竞争力的子域
通用域
通用功能子域
支撑域
不包含核心竞争力的功能，也不包含通用功能
通用语言
定义上下文含义。通过团队交流达成的公式，可以明确表述业务的逻辑。
包含了术语和用例场景，能够直接反映在代码中。其中的名词可以对应实体对象，动词对应领域事件或者命令。
- 事件风暴：领域专家，设计人员，开发人员建立领域模型，形成业务术语和用户故事，统一语言。
- 领域故事分析：形成领域对象，对应领域模型的业务对象，有通用的名词术语。
- 提取领域对象
- 领域对象与代码模型映射
- 代码落地：与领域对象一一对应
界限上下文中的术语统一，才能保证业务模型和代码一致。
限界上下文
定义语义所在的领域边界。
限界指的是领域的边界，上下文是语义环境。
保证领域之内的通用语言无二义性。
领域边界就是通过限界上下文来定义的。
将限界上下文的领域模型映射到微服务，就是问题域到软件的解决方案。
实体
有唯一标识符，且经历各种状态变更之后仍然保持一致。其延续性和标识会跨越软件的生命周期。实体是领域模型中的一个重要对象，是多个属性，操作的载体。对相关联度高的实体和值对象聚合之后，形成聚合。实体和值对象是组成领域模型的基础单元。代码中的实体类，通常采用充血模型，在实体类中实现相关的所有业务逻辑，跨越实体的领域规则在领域服务中实现。
实体对象都有唯一ID，构建领域模型后，构建实体对象和行为，最后将其映射到数据对象。实体和持久化对象可能是多对一或者一对多关系。
值对象
通过对象属性值来识别的对象，将多个相关属性组合为一个概念整体，没有标识服。
参考资料：
