DDD提升我的开发效率
2019年参加了"领域驱动设计峰会2019"看到了国内、国外、不同行业在基于DDD的实践分享。
成年热学习的一个特点就是带着自己的经验来思考接收到的内容,那么回顾自己接触DDD有一段时间,将自己的经验和思考作用在项目上,真真切切替换了DDD带给我的提升。
本片内容将不会聚焦在哪些理论上,而是看看那些些提升我开发效率的技术部分(非具体代码的粒度)。
- 充血模型 代替 贫血模型
- Domain + DomainService + ApplicationService
- 基础服务层
- 和业务保持一致
- 统一语言
01 用 充血模型 代替 贫血模型
充血模型的好处是让我最先感觉到收益的地方。
在之前的项目中很多都采用了三层的项目架构设计,短时间内看上去没有什么问题,但是随着项目的进行,Service层变得越来越臃肿,不得不加入其它的约束来让项目结构变得清晰。是的遇到问题、分析问题、解决问题。但是项目毕竟是个团队项目,所以有时候单个人遵守约束很容易,但是让团队都最受这种约束就变的困难的了,所以三层架构在原来的工作中确实带来了一部分问题。
是的,正如上面所言,在简单的场景下,采用贫血模型能够清楚的讲明白的。但是随着业务的丰富,想要通过代码接示业务意图变得异常的困难。
在接触DDD之后,项目开发中,领域模型使用了充血模型,一个领域对象上既包含属性又包含行为,能够保证业务实体为核心的灵活拓展。由采用充血模型避免了面向过程变成面向对象编程。散落在多个Service而不易发现重复的地方业务逻辑能够聚合在领域对象上。
是的,单考虑一个模型,感觉贫血模型会清楚,但是仅仅是感觉,实践之后会发现对充血模型的领域对象所包含的大致内容时序之后,充血模型能够更直白的得到自己期望的和业务相关的信息。
02 Domain + DomainService + ApplicationService
仅仅当领域对象采用充血模型的时候还不够。因为全部代码都放置在领域对象上是不合适的,所以,还需要另外两部分配合,它们是:DomainService、ApplicationService。它们各自承担一部分职责。
ApplicationService接受原始的数据或者Command(命令),它承担着领域实践的调度作用。但是不包含任务业务逻辑,保持对实现细节的黑盒。
DomainService并不是必须的,但是当有些业务逻辑出现在Domain上不合适的时候,我们可以将这部分逻辑放置在DomainService中。这样让Domian保持相对清晰的逻辑,同时不至于逻辑向上泄露到ApplicationService中。
03 基础服务层
和业务关系不大的,但是和技术关系紧密的,全部归为基础服务层。例如:
- 不含有业务的工具类
- 项目的Configuration
- 持久化Repository
- 和其他服务通信的feign
- 防腐层ACL
使用基础服务层最明显的感觉就是项目清晰明了,项目包含两部分业务部分、非业务部分。而基础服务层就是非业务的一部分。
举个简单的例子,在做包管理的时候,项目起初顶层有个包:resources、service、utils、config、domain、repository、feign等,随着项目的变化,又增加了新的exception包但是归到顶层包还是某个包下面,这就是纠结了,通过顶层我们看到的更多是技术上面的对包的描述。
采用了基础服务层,之后可以将和业务不想管的技术部分挪到infrastructure中,例如上面的exception包,如果包中描述的技术上需要的异常则直接放置在infrastructure,如果是通过异常表达业务意思,则可以放置在其他合适的包中。
04 和业务保持一致
这里的和业务保持一致,指的是类中的行为,无论是Controller,ApplicationService,DomainService,Doamin都是,通过类名、方法名可以知道这是在处理什么业务。做到开始的时候能够通过方法识别业务并不复杂,但是困难的是持续能够通过类名、方法名来表达业务。
在原来的三层的项目结构中,经过一段时间回头看看项目,想要在代码中找到自己想了解的完整的业务规则,并不是很容。原因就是Service中臃肿,但是在DDD的项目结构中,我们可以相对轻松的找到自己向获取到的信息。这方面我是感觉到阅读代码效率的提升的。
05 统一语言
最后就是统一语言,并不是所有的人都参与到Event Storming中去,但是Event Storming之后,整个团队在项目持续进行的过程中,可以始终围绕着领域模型来进行无歧义沟通。
统一语言是一个持续的过程,当业务发生变更时,领域模型同样需要同步进行变动,进入到新的版本。
基于统一的语言,我们清楚知道要实现什么来满足业务需求,同时也知道领域模型会发生什么变化。当领域模型随着项目的进行逐渐变变得庞大,我们依然知道主线在哪里。从而能够快速的做出做出反应,来应对这种变化。
以为沟通中没有了翻译,所以沟通就不会变的迟钝。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
《沙盘模拟系列》JVM如何调优
纸上得来终觉浅 绝知此事要躬行 我所在的公司基本上是没有机会进行JVM参数调优的,但是如果有些东西自己不亲身经历一下,看再多的理论知识也只能算是纸上谈兵,真正碰到问题的时候还是不知道该怎么分析。所以就自己制造一些问题然后看其现象,利用所学的知识事前推测,看现象是不是和自己推测的一样。这样不仅对自己所学的知识又是一次巩固,而且也能锻炼自己解决问题的能力(虽然问题是自己制造的)。 其实在写这篇文章之前已经看过好好几遍关于JVM调优那一块的内容,无论是书还是博客,但是大都看完了感觉自己懂了,但是真正自己模拟操作的时候又觉得什么都不会,但是经过自己模拟一遍以后发现能够将之前的知识都关联起来,形成了一个面,感觉理解有深了一点。这里强调一下希望大家看完以后,能够自己在机器上模拟一遍,采用不同的参数然后自己猜想结果并验证 工具准备 工欲善其事,必先利其器。在分析JVM之前我们需要先将工具准备一下,一个是可视化的垃圾回收工具,另一个是压测的工具。 GcViews安装 将GcViews代码从Git上下载下来github地址 在项目的根目录中执行命令mvn clean install 然后发现在根目录中生...
- 下一篇
从1+1=2来理解Java字节码
背景 前不久《深入理解Java虚拟机》第三版发布了,赶紧买来看了看新版的内容,这本书更新了很多新版本虚拟机的内容,还对以前的部分内容进行了重构,还是值得去看的。本着复习和巩固的态度,我决定来编译一个简单的类文件来分析Java的字节码内容,来帮助理解和巩固Java字节码知识,希望也对阅读本文的你有所帮助。 说明:本次采用的环境是OpenJdk12 编译“1+1”代码 首先我们需要写个简单的小程序,1+1的程序,学习就要从最简单的1+1开始,代码如下: package top.luozhou.test; /** * @description: * @author: luozhou * @create: 2019-12-25 21:28 **/ public class TestJava { public static void main(String[] args) { int a=1+1; System.out.println(a); } } 写好java类文件后,首先执行命令javac TestJava.java 编译类文件,生成TestJava.class。 然后执行反编译命令jav...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- CentOS关闭SELinux安全模块
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS8编译安装MySQL8.0.19
- CentOS7安装Docker,走上虚拟化容器引擎之路
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- CentOS7,8上快速安装Gitea,搭建Git服务器
- SpringBoot2整合Redis,开启缓存,提高访问速度
- CentOS7设置SWAP分区,小内存服务器的救世主