驱动领域DDD的微服务设计和开发实战(7)

根据领域模型中领域对象属性以及服务矩阵,画出领域对象及服务架构视图(如下图)。这个视图可以作为标准的 DDD 分层领域服务架构视图模型,应用在不同的领域模型中。这个模型可以清晰的体现微服务内实体、聚合之间的关系,各层服务之间的依赖关系以及应用层服务组合和编排的关系,微服务之间的服务调用以及事件驱动的前后处理逻辑关系。 在这个阶段,前端的设计也可以同步进行,在这里我们用到了微前端的设计理念,为请假和考勤微服务分别设计了请假和考勤微前端,基于微前端和微服务,形成从前端到后端的业务逻辑自包含组件。两个微前端之上有一个集成主页面,可根据页面流动态加载请假和考勤的微前端页面。

驱动领域DDD的微服务设计和开发实战

步骤四:代码模型设计¶

根据 DDD 的代码结构模型和各领域对象在所在的包、类和方法,定义出请假微服务的代码结构模型。应用层代码结构包括:应用服务以及事件发布相关代码(如下图)。

驱动领域DDD的微服务设计和开发实战

领域层代码结构包括一个或多个聚合的实体类以及领域服务相关代码(如下图)。在本项目中请假微服务领域层包含了请假和人员两个聚合。

驱动领域DDD的微服务设计和开发实战

领域模型中的一个聚合对应一个聚合代码包,如:人员和请假领域逻辑代码都放在各自的聚合代码包中,如随着业务发展,人员管理功能需要从请假微服务中拆分出来,我们只需要将人员聚合代码包稍加改造并独立部署即可快速发布为人员管理微服务。

步骤五:详细设计¶

在完成领域模型和代码模型设计后,我们就可以开始详细设计了,详细设计主要结合具体的业务功能来开展,主要工作包括:系统界面、数据库表以及字段、服务参数规约及功能等。

步骤六:代码开发¶

软件开发人员只需要按照设计文档和功能要求,找到业务功能对应的代码位置,完成代码开发和服务编排即可。

步骤七:测试和发布¶

完成代码开发后,由开发人员编写单元测试用例,基于挡板模拟依赖对象完成跨服务的测试。单元测试完成后,在团队内可进一步完成微服务与相应微前端的集成和测试,形成请假和考勤两个业务组件。前端主页面完成请假和考勤微前端页面集成和页面流及组件基础数据配置,主页面可以按照页面流程动态加载请假和考勤微前端页面。最终部署的软件包包括:请假和考勤两个微服务,请假和考勤两个微前端,一个主页面共计五个。这五个部署包独立开发、独立运行和独立部署。

技术组件说明¶

主页面和微前端采用:Vue(前端框架),ElementUI(UI 框架 -PC),VUX(UI 框架 - 移动端) 和 MPVUE(UI 框架 - 小程序) 等。微服务开发采用:Spring Cloud、Kafka、Redis 等。数据库采用:PostgreSQL。

附录一:DDD 名词和术语¶

Event Storming(事件风暴):事件风暴是一项团队活动,旨在通过领域事件识别出聚合根,进而划分微服务的限界上下文。在活动中,团队先通过头脑风暴的形式罗列出领域中所有的领域事件,整合之后形成最终的领域事件集合,然后对于每一个事件,标注出导致该事件的命令(Command),再然后为每个事件标注出命令发起方的角色,命令可以是用户发起,也可以是第三方系统调用或者是定时器触发等。最后对事件进行分类整理出聚合根以及限界上下文。

Entity(实体):每个实体是唯一的,并且可以相当长的一段时间内持续地变化。我们可以对实体做多次修改,故一个实体对象可能和它先前的状态大不相同。但是,由于它们拥有相同的身份标识,他们依然是同一个实体。例如一件商品在电商商品上下文中是一个实体,通过商品中台唯一的商品 id 来标示这个实体。

ValueObject(值对象):值对象用于度量和描述事物,当你只关心某个对象的属性时,该对象便可作为一个值对象。实体与值对象的区别在于唯一的身份标识和可变性。当一个对象用于描述一个事物,但是又没有唯一标示,那么它就是一个值对象。例如商品中的商品类别,类别就没有一个唯一标识,通过图书、服装等这些值就能明确表示这个商品类别。

Aggregate(聚合):聚合是实体的升级,是由一组与生俱来就密切相关实体和值对象组合而成的,整个组合的最上层实体就是聚合。

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/b48d0518c2a744d7fb545cb1872ea66c.html