如何避免写出烂的业务代码（2）-DDD整改

一. 背景

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

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

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

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

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

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

二. 工程架构图演进

现状

目前的系统结构图通常下面这样

四层 controller/service/manager/mapper

不可以同级调用

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

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

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

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

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

改进

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

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

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

三. 领域识别

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

演变的领域

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

四. 领域模型与微服务化

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

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