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 基础服务层

和业务关系不大的,但是和技术关系紧密的,全部归为基础服务层。例如:

  1. 不含有业务的工具类
  2. 项目的Configuration
  3. 持久化Repository
  4. 和其他服务通信的feign
  5. 防腐层ACL

使用基础服务层最明显的感觉就是项目清晰明了,项目包含两部分业务部分、非业务部分。而基础服务层就是非业务的一部分。

举个简单的例子,在做包管理的时候,项目起初顶层有个包:resources、service、utils、config、domain、repository、feign等,随着项目的变化,又增加了新的exception包但是归到顶层包还是某个包下面,这就是纠结了,通过顶层我们看到的更多是技术上面的对包的描述。

采用了基础服务层,之后可以将和业务不想管的技术部分挪到infrastructure中,例如上面的exception包,如果包中描述的技术上需要的异常则直接放置在infrastructure,如果是通过异常表达业务意思,则可以放置在其他合适的包中。

04 和业务保持一致

这里的和业务保持一致,指的是类中的行为,无论是Controller,ApplicationService,DomainService,Doamin都是,通过类名、方法名可以知道这是在处理什么业务。做到开始的时候能够通过方法识别业务并不复杂,但是困难的是持续能够通过类名、方法名来表达业务。

在原来的三层的项目结构中,经过一段时间回头看看项目,想要在代码中找到自己想了解的完整的业务规则,并不是很容。原因就是Service中臃肿,但是在DDD的项目结构中,我们可以相对轻松的找到自己向获取到的信息。这方面我是感觉到阅读代码效率的提升的。

05 统一语言

最后就是统一语言,并不是所有的人都参与到Event Storming中去,但是Event Storming之后,整个团队在项目持续进行的过程中,可以始终围绕着领域模型来进行无歧义沟通

统一语言是一个持续的过程,当业务发生变更时,领域模型同样需要同步进行变动,进入到新的版本。

基于统一的语言,我们清楚知道要实现什么来满足业务需求,同时也知道领域模型会发生什么变化。当领域模型随着项目的进行逐渐变变得庞大,我们依然知道主线在哪里。从而能够快速的做出做出反应,来应对这种变化。

以为沟通中没有了翻译,所以沟通就不会变的迟钝。


参考:
《ThoughtWorks洞见 领域驱动设计》

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 200,527评论 5 470
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 84,314评论 2 377
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 147,535评论 0 332
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,006评论 1 272
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 62,961评论 5 360
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,220评论 1 277
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,664评论 3 392
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,351评论 0 254
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,481评论 1 294
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,397评论 2 317
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,443评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,123评论 3 315
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,713评论 3 303
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,801评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,010评论 1 255
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,494评论 2 346
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,075评论 2 341

推荐阅读更多精彩内容