一.前言
hello,everyone。周末我开通了我的公众号:柏炎大叔
。会与掘金同步发布系列文章,可以加个关注,第一时间收到我的推文。
DDD的微信群我也已经建好了,由于文章内不能放二维码,大家可以加我微信baiyan_lou
,备注DDD交流,我拉你进群,欢迎交流共同进步。
DDD系列Demo被好多读者催更。肝了一周,参考了众多资料,与众多DDD领域的大佬进行了结构与理念的沟通后,终于完成了改良版的代码层次结构。
本文将给大家展开讲一讲
- 为什么我们要使用DDD?
- 到底什么样的系统适配DDD?
- DDD的代码怎么做,为什么要这么做?
你可以直接阅读本文,但我建议先阅读:一文带你落地DDD,如果你对DDD已经有过了解与认知,请直接阅读。
干货直接上,点此查看demo代码,配合代码阅读本文,体验更深,别忘了star~
DDD系列博客
我的第一本掘金小册《深入浅出DDD》已经在掘金上线,欢迎大家试读~
二.为什么我们要使用DDD
虽然我在第一篇DDD的系列文:一文带你落地DDD中已经做过介绍我们使用DDD的理由。但是对于业务架构不太熟悉的同学还是无法get到DDD的优势是什么。
作为程序员嘛,我还是比较提倡大家多思考,多扎实自己的基础知识的。面试突击文虽香,但是,面试毕竟像是考试,更多时候我们还是需要在一家公司里面去工作。别人升职加薪,你怨声载道,最后跳槽加小几千没有意义嘛。
言归正传,我相信基本上99%的java开发读者,不管你是计科专业出身还是跨专业,初学spring或者springboot的时候,接触到的代码分层都是MVC。
这说明了MVC有它自身独有的优势:
- 开发人员可以只关注整个结构中的其中某一层;
- 可以很容易的用新的实现来替换原有层次的实现;
- 可以降低层与层之间的依赖;
- 有利于标准化;
- 利于各层逻辑的复用。
但是真实情况是这样吗?随着你系统功能迭代,业务逻辑越来越复杂之后。MVC三层中,V层作为数据载体,C层作为逻辑路由都是很薄的一层,大量的代码都堆积在了M层(模型层)。一个service的类,动辄几百上千行,大的甚至几万行,逻辑嵌套复杂,主业务逻辑不清晰。service做的稍微轻量化一点的,代码就像是胶水,把数据库执行逻辑与控制返回给前端的逻辑胶在一起,主次不清晰。
一看你的工程,类啊,代码量啊都不少,你甚至不知道如何入手去修改“屎山”一样的代码。
归根到底的原因是什么?
service承载了它这个年纪不该承受的业务逻辑。
举个例子: 你负责了一个项目的从0到1的搭建,后面业务越来越好,招了新的研发进来。新的研发跟你一起开发,service层逻辑方法类似有不完全相同,为了偷懒,拷贝了你的代码,改了一小段逻辑。这时候基本上你的代码量已经是乘以2了。同理再来一个人,你的代码量可能乘了4。然而作为数据载体的POJO繁多,里面空空如也,你想把逻辑放进去,却发现无从入手。POJO的贫血模型
陷入了恶性循环。
那么DDD为什么可以去解决以上的问题呢?
DDD核心思想是什么呢?解耦!让业务不是像炒大锅饭一样混在一起,而是一道道工序复杂的美食,都有他们自己独立的做法。
DDD的价值观里面,任何业务都是某个业务领域模型的职责体现。A领域只会去做A领域的事情,A领域想去修改B领域,需要找中介(防腐层)去对B领域完成操作。我想完成一个很长的业务逻辑动作,在划分好业务边界之后,交给业务服务的编排者(应用服务)去组织业务模型(聚合)完成逻辑。
这样,每个服务(领域)只会做自己业务边界内的事情,最小细粒度的去定义需求的实现。原先空空的贫血模型
摇身一变变成了充血模型
。原理冗长的service里面类似到处set,get值这种与业务逻辑无关的数据载体包装代码,都会被去除,进到应用服务
层,你的代码就是你的业务逻辑。逻辑清晰,可维护性高!
三.到底什么样的系统适配DDD
看完上文对于DDD的分析之后是不是觉得MVC一对比简直就是垃圾。但是你回过头来想想,DDD其实在10几年前就已经被提出来了,但为什么是近几年才开始逐渐进入大众的视野?
相信没有看过我之前DDD的文章的同学看了我上面的分析大概也能感觉的到,DDD这个系统不像MVC结构那么简单,分层肯定更加复杂。
因此不是适配DDD的系统是什么呢?
中小规模的系统,本身业务体量小,功能单一,选择mvc架构无疑是最好的。
项目化交付的系统,研发周期短,一天到晚按照甲方的需求定制功能。
相反的,适配DDD的系统是什么呢?
中大规模系统,产品化模式,业务可持续迭代,可预见的业务逻辑复杂性的系统。
总而言之就是:
你还不了解DDD或者你们系统功能简单,就选择MVC.
你不知道选用什么技术架构做开发,业务探索阶段,选用MVC.
其他时候酌情考虑上DDD。
四.DDD的代码怎么做,为什么要这么做
4.1.经典分层
在用户界面层和业务逻辑层中间加了应用层(Application Layer) , 业务逻辑层改为领域层, 数据访问层改为基础设施层(Infrastructure Layer) , 突破之前数据库访问的限制。 固有的思维中,依赖是自顶向下传递的,用户界面依赖应用层,应用层依赖领域层和基础设施层,越往下的层,与业务越远,并更加通用;出于重用的考虑,通用的功能会剥离成框架或者平台,而在低层次(基础设施层)会调用、依赖这些框架,也就导致了业务对象(领域层)依赖外部平台或框架。
4.2.依赖倒置分层
为了突破这种违背本身业务领域的依赖,将基础设施往上提,当领域服务与基础设置有交集时,定义一个接口(灰度接口)
,让基础设施去实现对应的接口。接口本身是介于应用服务与领域服务之间的,为了纯净化领域层而存在。
这么做的好处就是,从分包逻辑来看,上层依赖下层,底层业务域不依赖任何一方,领域独立。
4.3.DDD分层请求调用链
4.3.1.增删改
1.用户交互层发起请求
2.应用服务层编排业务逻辑【仅做方法编排,不处理任何逻辑】
3.编排逻辑如果依赖三方rpc,则定义adapter,方式三方服务字段影响到本服务。
4.编排逻辑如果依赖其他领域服务,应用服务,可直接调用,无需转化。但是与当前框架不相符合的,例如发送短信这种,最好还是走一下适配器,运营商换了,依赖的应用服务没准都不同了。
5.聚合根本身无法处理的业务在领域层处理,依赖倒置原则,建立一层interfaces层(灰度防腐层),放置领域层与基础设置的耦合。
6.逻辑处理结束,调用仓储聚合方法。
4.3.2.查询
CQRS模型,与增删改不同的应用服务,是查询应用服务。不必遵守DDD分层规则(不会对数据做修改)。简单逻辑甚至可以直接由controller层调用仓储层返回数据。
五.总结
其实DDD在分层上从始至终一致在贯穿的一个逻辑就是,解耦。如果真的极端推崇者,每一层,每一步都会增加一个适配器。我觉得这个对于研发来说实在太痛苦了,还是要在架构与实际研发上做一个中和。
六.特别鸣谢
七.联系我
文中如有不正确之处,欢迎指正,写文不易,点个赞吧,么么哒~
钉钉:louyanfeng25
微信:baiyan_lou
公众号:柏炎大叔