领域驱动设计

理念

1. 开发人员和领域专家一起建立领域模型，开发人员包括分析设计人员和程序编写人员。
2. 领域模型是开发人员和领域专家之间交流的桥梁，采用统一语言进行建模。
3. 统一语言指开发人员和领域专家都明白和认可的图形和文字术语及描述的集合。
4. 一般可以采用类图表示领域概念和关系，附加文字说明来建立领域模型。类图中的类必要时可以添加重要属性。
5. 分析设计建模人员应该既负责领域建模，也参与编程工作。
6. 分析和设计采用同一个领域模型进行分析和设计，不区分分析模型和设计模型，以保证领域模型不被丢弃，并一直有效，并且让程序开发人员也去理解领域模型。

设计与实践

1. 区分实体对象（Entity）和值对象（VO），都属于领域对象，领域模型里除了这两种元素外，还包括聚合根和领域服务（Domain Service）。
2. 聚合根对象可包含实体和值对象，大部分的聚合根只包含一个实体，也就是这个实体就是聚合根，小部分的聚合根包括两到三个实体。
3. 领域对象包含领域规则，而不是把很多领域规则（业务规则）放到服务层（service层，业务逻辑层），是谁的领域规则就放到谁那里。（比如密码加密？修改密码规则？数据校验规则？）
4. 采用分层模式分离域模型：用户界面层（表示层）、应用层、领域层、基础设施层。
5. 表示层是控制器（再向上就是分离的前端），主要用来响应前端的请求、检查前端发送过来的数据；应用层包含应用服务，应该用来实现用例，封装用例的业务流程，代码应该很少，调用领域层实现具体业务处理；领域层包含实体对象和领域服务，主要封装业务规则；基础设施层封装各类基础服务和数据访问（仓储对象）。仓储对象的调用在哪一层？（应用服务？）
6. 应该将系统按模块进行代码组织，在一个模块里包含此模块的用户界面层、应用层、领域层、基础设施层的代码。此处的模块是指由Bounded Context（BC，限界上下文）划分的不同部分，微服务的划分也应该按照限界上下文来进行（即按模块）
7. 微服务（即BC）之间的数据关联如何处理？（比如，订单处理模块要使用客户和工作人员信息怎么处理？使用时直接调用另一个服务获取？还是在本BC保持一个副本，然后通过消息进行同步？）