如何避免写出烂的业务代码（2）- DDD整改
一. 背景
何避免写出烂的业务代码（1）一文中介绍过如何避免写出烂的业务代码，这边谈一谈领域驱动模型的实践
目前很多的业务代码存在以下问题
- 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调用
潜在的问题目前的领域对象还是不够丰富 当领域对象多了，相同的编排/组合领域对象也可以成为一个独立的领域上下文，这时候如何定义这类领域