DDD领域驱动设计-概述-Ⅰ
阅读原文时间:2021年10月27日阅读:9

如果我看得更远,那是因为我站在巨人的肩膀上。(If I have seen further it is by standing on ye shoulder of Giants.)

                                                                                                                                                                                                                    Newtown,I. 1676

DDD:指领域驱动设计,是domain driven design的缩写。

介绍DDD基础知识的相关文章很多,本文就不普及相关的基础知识了,基础理论知识可参考如下文章:

1. 初识DDD

脚本式编程(dao+service)与DDD领域驱动模式区别如下:

其每一层的作用范围和含义如下:

1)展现层(Presentation Layer):负责以Restful的格式接受Web请求,然后将请求路由给Application层执行,并返回视图模型(View Model),其载体通常是DTO(Data Transfer Object);

2)应用层(Application Layer):主要负责获取输入,组装上下文,做输入校验,调用领域层做业务处理,如果需要的话,发送消息通知。当然,层次是开放的,若有需要,应用层也可以直接访问基础实施层;

3)领域层(Domain Layer):主要是封装了核心业务逻辑,并通过领域服务(Domain Service)和领域对象(Entities)的函数对外部提供业务逻辑的计算和处理;

4)基础实施层(Infrastructure Layer)主要包含Tunnel(数据通道)、防腐层,Config和Common。这里我们使用Tunnel这个概念来对所有的数据来源进行抽象,这些数据来源可以是数据库(MySQL,NoSql)、搜索引擎、文件系统、也可以是SOA服务等;Config负责应用的配置;Common是通用的工具类。

常见的领域驱动业务调用链过程如下图所示:

调用过程大致如下:

  1. 业务调用方基于网关传入DTO数据,为了便于区分业务场景,将DTO数据又细分为CQE三种模式的数据。
  2. 业务数据传入后,基于Spring Validation等模式做基础数据验证(如必填,格式,大小等基础验证);
  3. 数据进入到Controller层,并调用应用层相关的应用功能;
  4. 应用层不做具体的业务实现,只做编排处理,做业务的流程处理。应用层可做如下操作:
  • 应用层调用防腐层查询其他系统的数据;
  • 应用层调用仓库层查询本系统相关的数据;
  • 应用层调用工厂创建实体(简单实体,可在应用层直接生成);
  • 应用层调用第三方领域服务,实体或聚合根的方法处理业务逻辑;
  • 应用层调用仓库层保存数据;
  1. 工厂创建实体,简单的实体可不基于工厂创建;
  2. 领域层处理实体的行为,核心业务逻辑处理放在领域层,领域层可调用基础层的所有模块处理业务(领域层原则上不直接调用仓库层保存数据,保存数据应该放在应用层调用);
  3. 仓库实现层最终落地数据,进行数据存储(其他层不能直接与Tunnel(数据通道)交互,必须基于仓库层才可以);
  4. 一个业务行为结束后,若产生副作用,再应用层发出事件通知,其他模块再监听处理。(事件归属应用层还是领域层,网上各有不同的方案,本例是放在应用层。领域层本身只是内存化操作。等一个实体行为真正数据存储成功后,再发出事件,便于理解和维护。)

2. 巨人的肩膀

作者接触DDD相关知识,是从一篇名为《一文教会你如何写复杂业务的代码》的文章开始的。带着好奇,越看越有共鸣,初步发现了DDD的神奇之处并一发不可收拾,开始入坑DDD领域驱动设计。在查看DDD各种教程博客时,综合对比并摒弃一些低质量的博客,强烈推荐以下两位老师的系列教程。

阿里-张建飞:张老师的新书《代码精进之路》。

阿里-殷浩:

  1. 《DDD系列第一讲》
  2. 《DDD系列第二讲: 应用架构》
  3. 《DDD系列第三讲:Repository模式》
  4. 《DDD系列第四讲:领域层设计规范》
  5. 《DDD系列第五讲:如何避免写流水账代码》

3. 为什么要写DDD系列博客

在初步了解了DDD的相关知识后,作者的第一感受是:DDD概念很多,各种专业术语,一堆下来还有点复杂,看了理论知识,还是云里雾里。看了诸多理论博客,总结一句就是:“听君一席话,如是一席话”。似乎明白了,又似乎还是什么都不懂。

经过第一轮的理论知识打击后,作者决定还是继续学习。既然理论知识太多,那就在实践中去寻找真理。

DDD到底应该怎样落地?

网上介绍DDD理论知识的相关文章很多,但真正介绍DDD如何应用在项目中的高质量技术文章就凤毛麟角了,更别提有完整示例的项目了。在这个探索的过程中,作者发现了殷浩的系列DDD教程,张建飞的COLA 4.0开源项目。

为了更透彻的掌握DDD相关的知识细节,并考虑落地DDD模式到公司的项目,还是没有采用开源项目COLA 4.0。作者选择通过殷浩老师的系列教程,一步一步开始DDD的探索之路。

适逢公司刚好存在一个老项目急需改造,老系统是基于(dao+service)脚本式编程开发的。由于时间较远且不同时间段由不同的开发人员维护,这种老代码,呵呵呵,懂的都懂。团队讨论决定就用这个项目来做DDD的落地。

虽然一开始看了很多理论知识文档,一些技术实现细节文档。但在编写初版本的DDD设计文档时,依旧发现特别的别扭,总感觉很奇怪。本质原因还是缺乏DDD设计经验,并且对DDD的各个知识点,分层细节理解不够深入。在这个迷茫阶段,作者抱着试一试的心态,尝试加了殷浩老师的钉钉,所幸他同意了。后续就是请教学习了,请教各种理论细节的实现和注意事项。在这个过程中,有以下几点感想:

  1. 深入理解理论知识,需要落地去反复的验证,总结出来的理论知识一般具有高度的概括性,为什么是这样,不这样会如何往往需要自己去验证;
  2. 自以为已经明白了理论知识,但在实际项目使用中,却是错误的使用,比如仓库层,领域层的一些细节问题;
  3. DDD落地困难的点还在于实现一个功能可以有不同的模式,这些模式不一定都对,但从功能实现层面来说却是都可以完成功能。比如,你在领域层直接调用仓库层保存数据,但领域层本身只是做纯内存化的业务逻辑处理,领域层是不可直接操作数据的。诸如此类的问题,导致不同的人对DDD理解不同,实现模式也不同。由于每一层的标准,实现方案不完全不同,才导致了DDD落地的复杂性。
  4. DDD做设计时,不单是对领域层做业务设计,应该是拉通整个流程一起做设计。
  5. 实体,聚合根,这些概念在实际项目中落地到具体的业务场景时,需要反复的迭代设计。
  6. 规范无处不在,注重编程细节,小到名命,大到使用设计模式,都需要规范编码。DDD在不同的层面,需要开发人员更加注重规范,不可张冠李戴,错误如:在仓库层里面写业务逻辑。
  7. 特别感谢殷浩老师的耐心指导,技术人传道授业,简单而纯粹。这份技术人独有的编码情怀和工匠精神,很帅。

本文旨在为使用或学习DDD模式的同行者,提供一个快速的入门案例(案例gitHub地址),抛砖引玉,共同学习。目前网上还缺乏完善的DDD设计案例,本着相互探讨和学习的思想,现基于实际的案例,在脱敏处理后,详述DDD从理论到落地的流程。大致分为以下模块:

  1. 《DDD领域设计-案例-需求说明文档》
  2. 《DDD领域设计-案例-建模设计说明》
  3. 《DDD领域设计-项目目录结构说明》
  4. 《DDD领域设计-案例-源码使用说明》
  5. 《DDD领域设计-设计规范》

特别说明DDD落地的方案没有统一的标准,本系列文章采用的技术方案也不一定能完全实现DDD的思想。由于作者水平有限,在一些理解上面若出现偏差,欢迎指导和批评。