DDD从小白到入门

DDD实战篇四：基于DDD的微服务设计实例

项目的基本信息：
项目的目标是实现在线请假和考勤管理，功能描述如下：
1、请假人填写请假单提交审批，根据请假人身份、请假类型和请假天数进行校验，
根据审批规则逐级递交上级审批，逐级核批通过则完成审批，否则审批不通过退回申请人。
2、根据考勤规则，核销请假数据后，对考勤数据进行校验，输出考勤统计

战略设计：战略设计是根据用户旅程分析，找出领域对象和聚合根，对实体和值对象进行聚类组成聚合，划分限界上下文，建立领域模型的过程。战略设计主要包括：产品愿景、场景分析、领域建模和微服务拆分等四个主要过程。

1、产品愿景：产品愿景是对产品顶层价值设计，对产品目标用户、核心价值、差异化竞争点等信息达成一致，避免产品偏离方向。

2、场景分析：场景分析是从用户视角出发，探索业务领域中点典型场景，产出领域中需要支撑的场景分类、用例操作以及不同子域之间的依赖关系，用以支撑领域建模。

3、领域建模：领域建模是通过对业务和问题域进行分析，建立领域模型。向上通过限界上下文知道微服务边界设计，向下通过聚合知道实体对象设计。

	领域建模是一个收敛的过程：
		第一步是找出领域实体和值对象等领域对象。
		第二步是找出聚合根，根据实体、值对象与聚合根的依赖关系，建立聚合
		第三步根据业务及语义边界等因素，定义限界上下文。

4、微服务的拆分：理论上一个限界上下文就可以设计为一个微服务，但需要综合考虑多种外部因素，比如：职责单一性、敏态与稳态业务分离、非功能性需求（如弹性伸缩、版本发布频率和安全等要求）、软件包大小、团队沟通效率和技术异构等非业务要素。

战术设计：战术设计是根据领域模型进行微服务设计的过程，这个阶段主要梳理微服务内的领域对象，梳理领域对象之间的关系，确定它们在代码模型和分层架构中的位置，建立领域模型与微服务模型的映射关系，以及服务之间的依赖关系。战术设计主要包括以下两个方面：

1、分析微服务领域对象：领域模型有很多领域对象，但是这些对象带有比较重的业务属性。要完成从领域模型到微服务的落地，还需要进一步的分析和设计。在事件风暴基础上，我们进一步细化领域对象以及它们的关系，补充事件风暴可能遗漏的业务和技术细节。

	服务的识别和设计：事件风暴的命令是外部的一些操作和业务行为，也是微服务对外提供的能力。它往往与微服务的应用服务或者领域服务对应。
				我们可以将命令作为服务识别和设计的起点。具体步骤如下：
					1、根据命令设计应用服务，确定应用服务的功能，服务集合，组合和编排方式。服务集合中的服务包括领域服务或其他微服务的应用服务。

					2、根据应用服务功能要求设计领域服务，定义领域服务。这里需要注意：应用服务可能是由多个聚合的领域服务组合而成的。

					3、根据领域服务的功能，确定领域服务内的实体以及功能

					4、设计实体基本属性和方法、领域事件的异步化处理聚合中的对象：在人员组织关系聚合中，我们可以建立人员之间的组织关系，
					通过组织关系类型找到上级审批领导，它的聚合根是人员。实体有组织关系（包括组织关系和上级审批领导）。其中组织关系类型
					（如项目经理、处长、总经理等）是值对象，上级审批领导来源于人员聚合根，可设计为值对象。人员组织关系聚合将包含以下值对象：组织关系类型、上级审批领导。
	微服务内的对象清单：在确定各领域对象的属性后，我们就可以设计各领域对象在代码模型中的代码对象（包括代码对象的包名、类名和方法名），建立领域对象与代码对象的一一映射关系
	了。根据这种映射关系，相关人员可快速定位到业务逻辑所在的代码位置。

2、设计微服务代码结构：应用层代码结构：应用层包括应用服务、DTO以及事件发布相关代码，在LeaveApplicationService类实现与聚合相关的应用服务，在LoginApplicationService封装外部微服务认证和权限的应用服务。
注：如果应用服务逻辑复杂的话，一个应用服务就可以构建一个类，这样可避免一个类的代码过于庞大，不利于维护。

领域层代码结构：领域层包括一个或多个聚合的实体类、事件实体类、领域服务以及工厂、仓储相关代码。一个聚合对应一个聚合代码目录，聚合之间在代码上完全隔离，聚合之间通过应用层协调。

后续的工作：
1、详细设计：在完成领域模型和微服务设计后，我们还需要对微服务进行详细的设计，主要设计实体属性、数据库表和字段、实体与数据库表映射、服务参数规约及功能实现等。

2、代码开发和测试：开发人员只需要按照详细的设计文档和功能要求，找到业务功能对应的代码位置，完成代码开发就可以了。代码开发完成后，开发人员要编写单元测试用例，基于挡板模板依赖对象完成服务测试。

本篇文章以实现请假和考勤管理而进行了战略设计和战术设计，下篇文章将总结微服务设计和拆分的原则以及分布式架构关键设计的10个关键问题。