领域模型驱动开发(2)-工程结构的调整

一. 背景

目前很多的业务代码存在以下问题

  1. bean的创建太随意,基本就是一个需求一些对应的dto,vo,query bean。

  2. 不同开发者对于同一个领域的东西有不同的bean,同一个开发者对于相同逻辑的bean,在经过2月+的时间,自己又定义出了一个差不多的bean -> 职责分散

  3. 不同开发者对于某块相同业务的逻辑校验放在了不同的service中 ->代码逻辑重复

  4. 不同的后端/前端对接时,相同概念的命名存在差异,导致后面重构时数据访问沉淀到manager层,上层调用的时候处理case有问题

  5. DTO类型的bean重构过程中根本不知道哪些是可以为Null,哪些不可以
    根本没有上下文/边界的概念,比如说模块A会和模块B有交互,模块C会和模块B有交互,通常在DB存储时只会存关联id,然后需要去取对应的名称,其他属性信息。
    这些信息的获取,有些开发在manager层操作,然后将属性定义到了模块A相关的DTO中,有些放在了service层做,对于模块B的有效性校验,也是在不同的service中

二. 工程架构图演进

现状

目前的系统结构图通常下面这样
这里写图片描述

  1. 四层 controller/service/manager/mapper

  2. 不可以同级调用

  3. 上级可以知晓下级,下级不可知晓上级,也就是bean的转化放在上级

这个分层结构和领域模型对应一下就会发现有些问题

  1. 资源服务层repository是面向DB编程

  2. service层是面向前端页面编程。

这样对于某一块的业务,还是没有将逻辑抽象到一起,也就不可避免的逻辑冗余

改进

这里写图片描述

  1. service层只能调用自己领域的manager

  2. 增加一层Facade层,专门处理与其他领域的交互(如果业务还没有这么复杂,加上层级太多影响开发效率,
    可以采用FacadeXXXService来标识这个类专门处理与其他领域的交互)
    这样调整以后结构清晰了许多了,manager层只处理自己领域的数据/缓存,service层处理自己领域的业务。与外界交互都在自己Facade层。

虽然这些改造都只是包结构的调整,但对于一个持续迭代的多人项目开发,带来的好处是能够快速了解某一块业务,当新人写这块业务的时候,能够写在对应的模块,能够利用已经写好的逻辑/bean.

三. 领域识别

领域演进
. 明确的领域
这些领域概念比较清晰,在业界比较通用在一开始就能明确,比如用户,商品,订单

演变的领域

有些业务是不断演进的,一个领域也会裂表为多个领域,比如订单和支付。
也有一些比较模糊的领域区分,比如商品清单这边有个清单业务,将商品添加到清单,就是一个collection,DB的设计也就是关联id而已,它能够划分到商品领域吗,不能,因为它不属于商品,没有它不影响商品业务。
清单只是一个展示商品的地方。那他能成为一个单独的领域,也很勉强,因为它的概念比较单薄,可以抽象出来的东西比较少,对于这类的问题,建议是在类级别做区分,当它的概念不断增加,领域不断丰富时,抽出到单独的包,作为一个新的领域

#四. 领域模型与微服务化#
做上面结构的调整,除了能够提供代码规范性,另外一个好处就是做减小微服务化的改造代价。因为边界清晰,与其他业务的交互清晰。比如你有一个工程,规划了6个领域模块,当某个领域模块发展足够大,可以迁移出去作为一个独立的微服务部署,这时候只需要将它对应的service,manager包,以及对于的bean迁出即可。其他服务与它的交互可以由service改成soa调用

这里写图片描述
潜在的问题
目前的领域对象还是不够丰富
当领域对象多了,相同的编排/组合领域对象也可以成为一个独立的领域上下文,这时候如何定义这类领域

©️2020 CSDN 皮肤主题: Age of Ai 设计师: meimeiellie 返回首页
实付0元
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值