案例教你一步步设计DDD微服务项目

• 组织关系

但之后发现刷卡明细、考勤明细和考勤统计等实体没有聚合根。

这类就需要分情况处理。

刷卡明细、考勤明细和考勤统计等实体间相互独立，找不出聚合根，不是富领域模型，但它们一起完成考勤业务逻辑，具有高业务内聚性。考虑将这几个业务关联紧密的实体，放在一个考勤聚合内。

最终建立请假、人员组织关系和考勤聚合：

• 请假聚合有请假单、审批意见实体和审批规则等值对象

• 人员组织关系聚合有人员和组织关系等实体

• 考勤聚合有刷卡明细、考勤明细和考勤统计等实体

定义限界上下文

人员组织关系和请假，两个聚合共同完成请假业务，所以在请假限界上下文。

考勤聚合单独构成考勤统计限界上下文。

所以为业务划分请假和考勤统计两个限界上下文，建立请假和考勤两个领域模型。

微服务的拆分

=====================================================================

一般来说，一个限界上下文即可设计为一个微服务。

划分微服务主要考虑职责单一原则。根据限界上下文即可拆为请假和考勤两个微服务：

• 请假微服务包含人员组织关系和请假两个聚合

• 考勤微服务包含考勤聚合

战略设计结束。通过战略设计建立了领域模型，划分了微服务边界。

下一步战术设计了，即微服务设计。

战术设计

===================================================================

根据领域模型进行微服务设计的过程。

梳理微服务内的领域对象，梳理领域对象之间的关系，确定它们在代码模型和分层架构中的位置，建立领域模型与微服务模型的映射关系，以及服务之间的依赖关系。

战术设计包括如下阶段：

分析微服务领域对象

---

领域模型有很多领域对象，但这些对象带有比较重的业务属性。

微服务内应该有哪些服务？服务的分层？应用服务由哪些服务组合和编排完成？领域服务包括哪些实体和实体方法？哪个实体是聚合根？实体有哪些属性和方法？哪些对象应该设计为值对象等。

服务的识别和设计

---

可将命令作为服务识别和设计的起点，步骤如下：

• 根据命令设计应用服务，确定应用服务的功能，服务集合，组合和编排方式。服务集合中的服务包括领域服务或其它微服务的应用服务

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

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

• 设计实体基本属性和方法

考虑领域事件的异步化处理。

以提交审批为例，流程：

• 根据请假类型和时长，查询请假审批规则，获取下一步审批人的角色

• 根据审批角色从人员组织关系中查询下一审批人

• 为请假单分配审批人，并将审批规则保存至请假单

• 分析得需要在应用层和领域层设计以下服务和方法

• 应用层

提交审批应用服务。

• 领域层

领域服务有查询审批规则、修改请假流程信息服务、根据审批规则查询审批人服务，分别位于请假和人员组织关系聚合。

请假单实体有修改请假流程信息方法，审批规则值对象有查询审批规则方法。

人员实体有根据审批规则查询审批人方法

聚合中的对象

=====================================================================

请假聚合中，聚合根是请假单。

请假单经多级审批后，会产生多条审批意见，为方便查询，可将审批意见设计为实体。

请假审批通过后，会产生请假审批通过的领域事件，因此还会有请假事件实体。

请假聚合有如下实体：

• 审批意见（审批人、审批状态和审批意见）

• 请假事件实体

请假单聚合的值对象。请假人和下一审批人数据来源于人员组织关系聚合中的人员实体，可设计为值对象。

人员类型、请假类型和审批状态是枚举类型，可设为值对象。

确定请假审批规则后，审批规则也可作为请假单的值对象。请假单聚合将包含以下值对象：请假人、人员类型、请假类型、下一审批人、审批状态和审批规则。

• 请假聚合对象关系图

人员组织关系聚合中，可建立人员之间的组织关系，通过组织关系类型找到上级审批领导。

• 聚合根

人员

• 实体

组织关系（包括组织关系类型和上级审批领导），其中组织关系类型（如项目经理、处长、总经理等）是值对象。上级审批领导来源于人员聚合根，可设计为值对象

人员组织关系聚合包含以下值对象

• 组织关系类型

• 上级审批领导

• 人员组织关系聚合对象关系图

在确定各领域对象的属性后，我们就可以设计各领域对象在代码模型中的代码对象（包括代码对象的包名、类名和方法名），建立领域对象与代码对象的一一映射关系了。根据这种映射关系，相关人员可快速定位到业务逻辑所在的代码位置。在经过以上分析后，我们在微服务内就可以分析出如下图的对象清单。

应用层代码

---

应用层包括：应用服务、DTO以及事件发布相关代码。在LeaveApplicationService类内实现与聚合相关的应用服务，在LoginApplicationService封装外部微服务认证和权限的应用服务。

如果应用服务逻辑复杂的话，一个应用服务就可以构建一个类，这样可以避免一个类的代码过于庞大，不利于维护。

领域层代码

---

请假微服务领域层包含请假和人员两个聚合。人员和请假代码都放在各自的聚合所在目录结构的代码包中。如果随着业务发展，人员相关功能需要从请假微服务中拆分出来，我们只需将人员聚合代码包稍加改造，独立部署，即可快速发布为人员微服务。到这里，微服务内的领域对象，分层以及依赖关系就梳理清晰了。微服务的总体架构和代码模型也基本搭建完成了。

后续工作

===================================================================

详细设计

---

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

代码开发和测试

---

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

总结

=================================================================

DDD战略设计从事件风暴开始，然后我们要找出实体等领域对象，找出聚合根构建聚合，划分限界上下文，建立领域模型。

战术设计从事件风暴的命令开始，识别和设计服务，建立各层服务的依赖关系，设计微服务内的实体和值对象，找出微服务中所有的领域对象，并建立领域对象与代码对象的映射关系。

FAQ

==================================================================

最后

看完上述知识点如果你深感Java基础不够扎实，或者刷题刷的不够、知识不全面

小编专门为你量身定制了一套<Java一线大厂高岗面试题解析合集：JAVA基础-中级-高级面试+SSM框架+分布式+性能调优+微服务+并发编程+网络+设计模式+数据结构与算法>

针对知识面不够，也莫慌！还有一整套的<Java核心进阶手册>，可以瞬间查漏补缺

全都是一丢一丢的收集整理纯手打出来的

更有纯手绘的各大知识体系大纲，可供梳理：Java筑基、MySQL、Redis、并发编程、Spring、分布式高性能架构知识、微服务架构知识、开源框架知识点等等的xmind手绘图~

.(img-dbrPrrql-1714203661087)]

针对知识面不够，也莫慌！还有一整套的<Java核心进阶手册>，可以瞬间查漏补缺

[外链图片转存中…(img-hEZN2htY-1714203661087)]

全都是一丢一丢的收集整理纯手打出来的

更有纯手绘的各大知识体系大纲，可供梳理：Java筑基、MySQL、Redis、并发编程、Spring、分布式高性能架构知识、微服务架构知识、开源框架知识点等等的xmind手绘图~

[外链图片转存中…(img-DTjfztqI-1714203661088)]

[外链图片转存中…(img-Gw318Xvm-1714203661089)]

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录