畛域驱动实际总结三: 具体利用设计剖析

畛域驱动设计 DDD 是一种设计思维，它能够同时领导中台业务建模和微服务设计(中台实质是业务模型，微服务是业务模型的零碎落地)，畛域驱动设计强调畛域模型和微服务设计的一体性，先有畛域模型而后才有微服务，而不是脱离畛域模型来谈微服务设计。

微服务拆分窘境产生的根本原因: 不晓得业务或者微服务的边界到底在什么中央。

DDD 核心思想: 通过畛域驱动设计办法定义畛域模型，从而确定业务和利用边界，保障业务模型与代码模型的一致性。

对于畛域驱动设计的学习做的总结次要写三篇博客，次要包含三局部: 根本实践总结与剖析、架构剖析与代码设计、具体利用设计剖析，次要参考的材料为极客工夫的欧翻新架构师的《DDD》实战，其余参考书籍在文章下方的参考书籍中。

本次次要总结 DDD 具体利用设计剖析：

一、利用我的项目的根本背景

我的项目的指标是实现在线销假和考勤治理。性能形容如下：

• 销假人填写请假单提交审批，依据销假人身份、销假类型和销假天数进行校验，依据审批规定逐级递交下级审批，逐级核批通过则实现审批，否则审批不通过退回申请人。
• 依据考勤规定，核销销假数据后，对考勤数据进行校验，输入考勤统计。

备注：本想以大视频业务零碎为背景本人弄一个的，然而工夫太紧，临时还是以欧翻新架构师提供的案例做总结和剖析了解，前期有工夫会本人出一个对于视频零碎的。

二、针对我的项目进行畛域驱动的策略设计阶段

策略设计 * 采纳的办法是事件风暴 *，包含：* 产品愿景、场景剖析、领域建模和微服务拆分 * 等几个次要过程。

策略设计是依据用户旅程剖析，找出畛域对象和聚合根，对实体和值对象进行聚类组成聚合，划分限界上下文，建设畛域模型的过程。

策略设计阶段* 倡议参加人员 *：领域专家、业务需求方、产品经理、架构师、项目经理、开发经理和测试经理。

（一）事件风暴确定产品愿景

产品愿景是对产品顶层价值设计，对产品指标用户、外围价值、差异化竞争点等信息达成统一，防止产品偏离方向。

事件风暴时，所有参与者针对每一个要点，在贴纸上写出本人的意见，贴到白板上。

事件风暴主持者会对每个贴纸，探讨并对发散的意见进行收敛和对立，造成上面的产品愿景图。其实，也就是让所有人确定对立的大方向对立语言，咱们到底在干什么，目标和意义是什么等的根本问题。

产品愿景剖析对于初创零碎明确零碎建设重点，对立团队建设指标和建设通用语言是很有价值的。

针对本我的项目，最初确定的产品愿景图整顿成一段文字就是：

为了满足内外部人员，他们的在线销假、主动考勤统计和内部人员治理的需要，咱们建设这个在线销假考勤零碎，它是一个在线销假平台，能够主动考勤统计。它能够同时反对内外网销假，同时治理内外部人员销假和定期考勤剖析，而不像 HR 零碎，只治理内部人员，且只能内网应用。咱们的产品内外网皆可应用，可实现内外部人员无差别治理。

达到的目标与意义：

通过产品愿景剖析，我的项目团队对立了零碎名称——在线销假考勤零碎，明确了我的项目指标和要害性能，与竞品（HR）的要害差别以及本人的劣势和外围竞争力等。

（二）事件风暴进行业务场景剖析

场景剖析是* 从用户视角登程 *，摸索业务畛域中的典型场景，产出畛域中须要撑持的场景分类、用例操作以及不同子域之间的依赖关系，用以撑持领域建模。

我的项目团队成员一起用事件风暴剖析销假和考勤的用户旅程。

依据不同角色的旅程和场景剖析，尽可能全面地梳理从前端操作到后端业务逻辑产生的所有操作、命令、畛域事件以及内部依赖关系等信息。

以销假和人员场景作为示例 ————

场景剖析一：销假 用户：销假人

• 销假人登录零碎：从权限微服务获取销假人信息和权限数据，实现登录认证。
• 创立请假单：关上销假页面，抉择销假类型和起始工夫，录入销假信息。保留并创立请假单，提交销假审批。
• 批改请假单：查问请假单，关上销假页面，批改请假单，提交销假审批。
• 提交审批：获取审批规定，依据审批规定，从人员组织关系中获取审批人，给请假单调配审批人。

场景剖析二：审批 用户：审批人

• 审批人登录零碎：从权限微服务获取审批人信息和权限数据，实现登录认证。
• 获取请假单：获取审批人名下请假单，抉择请假单。
• 审批：填写审批意见。
• 逐级审批：如果还须要下级审批，依据审批规定，从人员组织关系中获取审批人，给请假单调配审批人。反复以上 4 步。最初审批人实现审批。

备注：实现审批后，产生销假审批已通过畛域事件。后续有两个进一步的业务操作：发送销假审批已通过的告诉，告诉邮件系统告知销假人；将销假数据发送到考勤以便核销。

场景剖析三：人员组织关系 具体的剖析过程以及考勤的场景剖析就不形容了

（三）事件风暴进行领域建模

领域建模是通过对业务和问题域进行剖析，建设畛域模型。

向上通过限界上下文领导微服务边界设计，向下通过聚合领导实体对象设计。

领域建模是一个收敛的过程，分三步：

第一步：找出畛域实体和值对象等畛域对象

依据场景剖析，剖析并找出发动或产生这些命令或畛域事件的实体和值对象，将与实体或值对象无关的命令和事件汇集到实体。

依据场景剖析，剖析并找出发动或产生这些命令或畛域事件的实体和值对象，将与实体或值对象无关的命令和事件汇集到实体。

（留神表白中的名词和动词等，名词往往是实体、值对象等，动词往往对应着命令的相干行为）

第二步：找出聚合根，依据实体、值对象与聚合根的依赖关系，建设聚合

定义聚合前，先找出聚合根。

从下面的实体中，咱们能够找出“请假单”和“人员”两个聚合根。而后找出与聚合根严密依赖的实体和值对象。咱们发现审批意见、审批规定和请假单严密关联，组织关系和人员严密关联。

找出这些实体的关系后，咱们发现还有 刷卡明细、考勤明细和考勤统计，这几个实体没有聚合根。这种情景在领域建模时你会常常遇到，对于这类场景咱们须要分状况非凡解决：

• 刷卡明细、考勤明细和考勤统计这几个实体，它们之间互相独立，找不出聚合根，不是富畛域模型，但它们一起实现考勤业务逻辑，具备很高的业务内聚性。
• 咱们将这几个业务关联严密的实体，放在一个考勤聚合内。
• 在微服务设计时，咱们仍然采纳 DDD 的设计和分析方法。因为没有聚合根来治理聚合内的实体，咱们能够用传统的办法来治理实体。

通过剖析，咱们建设了销假、人员组织关系和考勤三个聚合。其中销假聚合有请假单、审批意见实体和审批规定等值对象。人员组织关系聚合有人员和组织关系等实体。考勤聚合有刷卡明细、考勤明细和考勤统计等实体。

第三步：依据业务及语义边界等因素，定义限界上下文

因为人员组织关系聚合与销假聚合，共同完成销假的业务性能，两者在销假的限界上下文内。

考勤聚合则独自形成考勤统计限界上下文。

因而咱们为业务划分销假和考勤统计两个限界上下文，建设销假和考勤两个畛域模型。

（四）事件风暴进行微服务的拆分

实践上一个限界上下文就能够设计为一个微服务，但还须要综合思考多种内部因素，比方：职责单一性、敏态与稳态业务拆散、非功能性需要（如弹性伸缩、版本公布频率和平安等要求）、软件包大小、团队沟通效率和技术异构等非业务因素。

在这个我的项目，咱们划分微服务次要思考职责单一性准则。

因而依据限界上下文就能够拆分为销假和考勤两个微服务。其中销假微服务蕴含人员组织关系和销假两个聚合，考勤微服务蕴含考勤聚合。

三、针对我的项目进行畛域驱动的战术设计阶段

战术设计是* 依据畛域模型进行微服务设计的过程 *。这个阶段次要梳理微服务内的畛域对象，梳理畛域对象之间的关系，确定它们在代码模型和分层架构中的地位，建设畛域模型与微服务模型的映射关系，以及服务之间的依赖关系。

战术设计阶段* 倡议参加人员 *：领域专家、产品经理、架构师、项目经理、开发经理和测试经理等。战术设计包含以下阶段：

（一）剖析微服务畛域对象

在事件风暴根底上，咱们进一步细化畛域对象以及它们的关系，补充事件风暴可能脱漏的业务和技术细节：

• 咱们剖析微服务内应该有哪些服务？
• 服务的分层？
• 应用服务由哪些服务组合和编排实现？
• 畛域服务包含哪些实体和实体办法？
• 哪个实体是聚合根？
• 实体有哪些属性和办法？
• 哪些对象应该设计为值对象等。

1. 具体服务的辨认和设计

事件风暴的命令是内部的一些操作和业务行为，也是微服务对外提供的能力。它往往与微服务的应用服务或者畛域服务对应。咱们* 能够将命令作为服务辨认和设计的终点 *。

具体步骤如下：

• 依据命令设计应用服务，确定应用服务的性能，服务汇合，组合和编排形式。服务汇合中的服务包含畛域服务或其它微服务的应用服务。
• 依据应用服务性能要求设计畛域服务，定义畛域服务。这里须要留神：应用服务可能是由多个聚合的畛域服务组合而成的。
• 依据畛域服务的性能，确定畛域服务内的实体以及性能。
• 设计实体根本属性和办法。
• 思考畛域事件的异步化解决。

* 以提交审批这个动作为例 *，来阐明服务的辨认和设计。提交审批的大体流程是：

• 依据销假类型和时长，查问销假审批规定，获取下一步审批人的角色。
• 依据审批角色从人员组织关系中查问下一审批人。
• 为请假单调配审批人，并将审批规定保留至请假单。

通过剖析，咱们须要在应用层和畛域层设计以下服务和办法。

• 应用层：提交审批应用服务。
• 畛域层：畛域服务有查问审批规定、批改销假流程信息服务以及依据审批规定查问审批人服务，别离位于销假和人员组织关系聚合。请假单实体有批改销假流程信息办法，审批规定值对象有查问审批规定办法。人员实体有依据审批规定查问审批人办法。下图是咱们剖析进去的服务以及它们之间的依赖关系。

2. 聚合中的对象剖析

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

• 请假单经多级审核后，会产生多条审批意见，为了不便查问，咱们能够将审批意见设计为实体。
• 销假审批通过后，会产生销假审批通过的畛域事件，因而还会有销假事件实体。

销假聚合有以下* 实体 *：审批意见（记录审批人、审批状态和审批意见）和销假事件实体。

再来剖析一下请假单聚合的值对象。

• 销假人和下一审批人数据来源于人员组织关系聚合中的人员实体，可设计为值对象。
• 人员类型、销假类型和审批状态是枚举值类型，可设计为值对象。
• 确定销假审批规定后，审批规定也可作为请假单的值对象。

请假单聚合将蕴含以下* 值对象 *：销假人、人员类型、销假类型、下一审批人、审批状态和审批规定。

—————————————————————————————————————————————————–

* 人员组织关系聚合 *中，咱们能够建设人员之间的组织关系，通过组织关系类型找到下级审批领导。

它的聚合根是人员，实体有组织关系（包含组织关系类型和下级审批领导），其中组织关系类型（如项目经理、处长、总经理等）是值对象。下级审批领导来源于人员聚合根，可设计为值对象。人员组织关系聚合将蕴含以下 值对象：组织关系类型、下级审批领导。

3. 微服务内的对象清单

在确定各畛域对象的属性后，咱们就能够设计各畛域对象在代码模型中的代码对象（包含代码对象的包名、类名和办法名），建设畛域对象与代码对象的一一映射关系了。

依据这种映射关系，相干人员可疾速定位到业务逻辑所在的代码地位。

（二）设计微服务代码构造

依据 DDD 的代码模型和各畛域对象所在的包、类和办法，能够定义出销假微服务的代码构造，设计代码对象。

1. 应用层代码构造

应用层包含：应用服务、DTO 以及事件公布相干代码。

在 LeaveApplicationService 类内实现与聚合相干的应用服务，在 LoginApplicationService 封装内部微服务认证和权限的应用服务。

(揭示一下：如果应用服务逻辑简单的话，一个应用服务就能够构建一个类，这样能够防止一个类的代码过于宏大，不利于保护。)

2. 畛域层代码构造

畛域层包含一个或多个聚合的实体类、事件实体类、畛域服务以及工厂、仓储相干代码。

* 一个聚合对应一个聚合代码目录，聚合之间在代码上齐全隔离，聚合之间通过应用层协调 *。

销假微服务畛域层蕴含销假和人员两个聚合。人员和销假代码都放在各自的聚合所在目录构造的代码包中。

如果随着业务倒退，人员相干性能须要从销假微服务中拆分进去，咱们只需将人员聚合代码包稍加革新，独立部署，即可疾速公布为人员微服务。

（三）后续的工作：具体设计 + 代码开发和测试

1. 具体设计

在实现畛域模型和微服务设计后，咱们还须要对微服务进行具体的设计。

次要设计以下内容：实体属性、数据库表和字段、实体与数据库表映射、服务参数规约及性能实现等。

2. 代码开发和测试

开发人员只须要依照具体的设计文档和性能要求，找到业务性能对应的代码地位，实现代码开发就能够了。

代码开发实现后，开发人员要编写单元测试用例，基于挡板模仿依赖对象实现服务测试。

起源：https://zyfcodes.blog.csdn.ne…
欢送关注公众号【码农开花】一起学习成长
我会始终分享 Java 干货，也会分享收费的学习材料课程和面试宝典
回复：【计算机】【设计模式】【面试】有惊喜哦