电话机器人团队DDD实践

DDD是一套方法论,一套思想。种类繁多的元模型和名词概念。其本质都是指导思想对应的解决方案“之一”,初学者容易被表象所困。应始终清醒保持认知“DDD各种元模型都是为解决实际开发中某类问题而起”。在接触各类元模型时应结合自身业务面临问题来求证,这样有助于避免被概念表象所困,回归解决问题的本质。

 背景 

数据架构团队从18年开始,受业务需求驱动开发电话机器人,转眼已近5年。目前,在该平台下已搭建100+不同类型机器人,为公司经销商、二手车、主机厂、金融等多个BU业务提供外呼能力,日外呼量几十万通。电话机器人项目已初具规模,但过程中也遇到不少挑战。为了应对这些挑战,我们团队最终采用DDD思想进行重构和开发。

在应用DDD的过程中,数据架构团队落地了一些自己的开发规范。这里就把一些经验和想法分享给大家,希望能起到抛砖引玉作用。这里解释一下,篇幅中很多元模型没有展开讲,也没有给出具体案例。一是考虑到篇幅长度问题。二是理解了DDD思想,结合各自业务来实现就好了,给出在我业务的例子意义并不大。此外这类案例很容易找的到。同时,觉得给出我们团队遇到的问题、解决方案,落地过程和我们形成的开发规范对大家来说更有价值。对DDD感兴趣,想了解更多或对本文有疑问的同学,欢迎找我交流讨论。

下面,我从这几个部分来进行分享:机器人项目中遇到的挑战、为什么是DDD、DDD落地步骤、对团队带来的提升、理论到实战遇到的冲突以及未来在DDD应用方面的改进和总结。

 1.遇到的挑战 

► 挑战一:业务逻辑复杂度高。随着各类业务的接入,为应对不同场景下的特定业务,不断追加新逻辑。

如:流程中的意图识别逻辑。

意图识别需要依赖AI的多个模型识别,多个模型识别出来的意图有可能是冲突的,需要对冲突的意图配置规则做取舍。同时,对一些冷启动或者紧急优化的场景,需要支持通过配置规则实时生效的方式来意图识别。并且在规则的意图识别中需要支持匹配词槽。词槽的类型又有多种,从优先级上区分有场景的全局词槽、流程上的词槽。从数据识别来源上区分,可以分为AI识别出来的,词典规则匹配出来的,还可能是业务方传递进来的。业务开展一段时间后,不同类型的词槽又增加不同属性,如车系的词槽有本品、经营范围、非经营等等;

► 挑战二:代码架构结构不清晰。随着业务需求功能的追加,伴随着代码规模增大。加之逻辑复杂和团队开发人员代码迥异,逐渐导致各种逻辑边界变得混乱。

如:我们通常的开发方式,按功能模块拆解,业务流程串联协调各个模块,共同完成业务需求。但是处理这类业务复杂的逻辑,这种方案设计有很大的弊端,模块边界很容易被穿透。

各模块关系相互调用,原本作为模块的隔离设计,实际在实现过程被完完全全的打破了。使原本理想中垂直拆分的模块,变成网状的结构。

模块负责人中间环节开发出来的的属性或方法,被外部其它模块外依赖导致功能发散出去。导致后期需求变动时风险增加,又或是发现被依赖了原本可以随意更改的方法不能变动,不得不增加额外逻辑代码来实现。造成了本就复杂的代码更加复杂。

对业务需求拆解不合理,需求功能在实现时就近开发,未严格按照模块拆解,缺少统一思想作为指导。

► 挑战三:产品需求多,难以辨别是否有真实价值。

► 挑战四:逻辑变化快,不少需求导致需要代码逻辑重新设计。

► 挑战五:业务多,各业务表述不一致,沟通成本高。

垂直边界被打破,代码复杂度增加,加上业务流程频繁调整。这些多重维度相互叠加,使得开发和维护难度指数增加。电话机器人这个一级应用系统的稳定性难以保障。即便技术同学都是资深的工程师,已经按照所能理解的微服务思想设计、按照模块拆解项目,即便代码逻辑中已经也引用不少设计模式来构建与扩展,即便已经是接入了公司各个平台质量工具、写了不少单元测试。但是在项目新需求迭代时,依旧出现不少“惊喜”,使整个团队很头疼。

2.为什么是DDD

为什么是DDD?每天那么多技术栈,那么多思想,为什么就是DDD来应对呢?首先DDD修饰的很好“软件核心复杂性应对之道”,使得不少人想一探究竟。所以来看看DDD是怎么来解决项目中遇到的挑战。

► 首先,我们来看看DDD对复杂度的归类,弄明白DDD要应对的复杂度是否是我面临的挑战。DDD相关资料中,从理解能力和预测能力两个维度来探索剖析复杂度的成因。

理解能力(就是软件系统对开发人员来说复杂难以理解):

第一规模:影响理解能力的第一要素。几百上千万行的代码,各需求点的关系相互影响。修改一处就会牵一发动全身。

第二结构:不合理甚至混乱的结构,导致开发人员对功能难以维护。

预测能力(就是业务的发展难以预测):

当需求变化时,难以预测软件实现的走向,会出现过度设计和设计不足问题。过度设计,预留了很多接口,构造了很多模式增加了代码的实现复杂度,但后来发现用不到。设计不足,需求的实现没考虑到后期的发展,当变化来临时需要推翻现有设计重新开发,被产品抱怨设计能力差。

DDD对复杂度的成因归结为:规模、结构、变化;规模和结构制造了理解能力障碍,变化制造了预测能力障碍,两者相加形成了复杂度问题。

► 其次,DDD并不仅仅是对代码设计阶段的理论,而是还包含从需求分析、架构映射和建模及实现的全流程设计指导。

需求分析阶段,通过相关指导思想提前准确获知业务价值,捕获未来变化方向。架构映射阶段,给出从需求到架构过程的指导思想,增加了设计权重和规范。通过子领域拆分、系统分层和限界上下文业务归类,给出指导规范,保障了系统架构的清晰,并且降低系统复杂度。建模及实现阶段,给出来领域驱动设计相关元模型,使各部分职能分工明确,快速响应业务需求和未来功能变化。

► 再次,来看DDD给出的指导思想:

规模问题:拆边界。以子领域、限界上下文对拆解分治。

针对分治思想,DDD给出两个重要的设计元模型:限界上下文和上下文映射。

结构问题:分层架构+限界隔离。

分层起到了隔离业务逻辑和技术实现复杂度问题。DDD引入的分层架构,将业务逻辑封装到领域层,支撑业务逻辑的技术实现放到基础设施层。在领域层之上的应用层封装应用服务,粘合二者进行协作。

变化问题:主动设计变化。

变化无法控制,只能拥抱变化。需求分析阶段运用5W思维识别变化规律,把控业务变化。DDD通过模型驱动设计元模型对限界上下文进行领域建模,形成结合分析、设计和实现一体的领域模型。

►最后,来看DDD给出的解决方案。其引入了一套提炼为模式的设计元模型,对业务软件做到了对规模的控制、结构的拆分以及变化的主动响应。

 简单介绍下这张图,整体分为两个大部分。第一部分是下面虚线圈出来的部分,不涉及具体技术实现。在需求分析阶段进行的,应对问题空间的一些元模型方案。另外部分,在第一部分的基础上,做具体系统架构分层、对象抽离聚合、服务拆解环节,这个阶段做对应的设计落地。

我的理解是这样,这套设计元模型给出了从需求分析、设计和实现一体整套解决方案。需求分析阶段的系统拆解(对应图中子领域元模型)。再拆到更新粒度的限界上下文。并给出各限界的协同关系方案(对应图中上下文映射元模型)。设计实现阶段给出模型驱动设计的设计元方案,通过系统的分层架构、领域服务、聚合等粒度的设计。给出一套完善的、有理论支撑的、可落地有标准的解决方案。

上述DDD对问题复杂度的剖析定位,完全就是电话机器人系统中的痛点。给出的解决方案,也完美解决业务面临的各类挑战。认识到其价值后,团队很快达成共识在后续的项目中进行落地。

3. DDD落地步骤 

元模型细节、业务限界的拆解不展开讲了,直接给出我们团队实战中的步骤和产物。

3.1 第一步预研阶段

这部分我们的经验是团队中有人充当先行者,先花费精力做深入学习DDD相关理念,然后同步到整个团队。就我们团队来讲,调研阶段时间比较零碎不好评估用时多久,团队科普阶段前后4次用时8小时。之后,团队内同学在有概念指导的基础上,已具备快速深入学习能力。并组织团队成内相互探讨印证理解。

3.2 第二步引入指导思想和落地规范

 ►3.2.1 需求分析阶段引入5W模型理论支撑,有助辨识出真实需求,主动把控变化方向和排除无意义需求。

这部分就是5W理论作为跟产品分析需求的理论的支撑,非常有助于识别出真实的需求,更好的分析出业务的发展方向。也能从源头上缩减无效需求,直接上图;图片

►3.2.2 引入服务规约,以文档型对照代码业务功能实现。有助于开发及后续需求梳理,同时也能作为单元测试覆盖度的考量。

⬤ 3.2.2.1 团队成员共识,需求先写服务规约,再做开发。写服务规约的时间,其实就是技术对需求理解的梳理,理清了思路,后续写代码时把这部分时间赚回来。

⬤ 3.2.2.2 服务规约及需求,服务规约即对应单测。顺带解决了先前单测没有标准(我理解的代码、方法覆盖率这类,不能称作为标准)的问题。

►这里给出我们团队采用的服务规约模板:

编号:标记业务服务的唯一编号。

名称:动词短语形式的业务服务名。

描述:

         作为<角色>

         我想要<服务功能>

          以便于<服务价值>

触发事件:

角色主动触发的该业务服务事件,可以是点击UI的控件、具体的策略或伴生系统发送的消息等。

基本流程:

用于表现业务服务的主流程,即执行成功的业务场景。也可以称之为“主成功场景”。

替代流程:

用于表现业务服务的扩展流程,即执行失败的业务场景。

验收标准:一系列可以接受的条件或业务规则,以要点形式列举。

3.3 第三步确定架构方案

学习DDD中模型驱动设计元模型的方案。主要是划分职责边界,也就是限界上下文,达到从传统网状结构关系变为垂直切分关系,减少彼此依赖。整体采用限界上线文拆解加菱形驱动设计,形成整体思想指导。系统采用分层架构 COLA 4.0图片

3.4 第四步共识命名标准

形成团队编码规范

 团队内共识包命名、类命名、出参入参的消息契约等规范。这里想说的是参考标准就是没有标准。希望大家先能理解DDD思想,然后参照学习业内共识性高的命名方案。同时需要兼顾团队内成员编程风格喜好,最终来制定自己团队的编码规范。

依我们入参、出参消息命名来举例。综合各方考量,并没有采用上图粒度特别细的命名方式。而是团队内简单共识为入参*request,出参*reponse命名标准。

3.5 第五步 结合业务特征识别出限界上下文

 基于DDD思想,对业务进行事件风暴,在统一语言的指导下做全局需求分析、架构映射设计,识别出业务的限界上下文。

技术同学结合自身业务来设计,参照Demo资料还是比较容易找的到,这里不再赘述。这里给出识别限界上下文的一个指导过程,V型映射过程。图片

3.6 最后进入建模的实现阶段

建议采测试驱动开发的方式进行编码,即用红绿黄驱动;图片

该方式遵循其三定律,这样能改善对需求的设计不足和过度设计问题。

定律一一次只写一个刚好失败的测试,作为新加功能的描述。
定律二不写任何产品代码,除非它刚好能让失败的测试通过。
定律三只在测试全部通过的前提下做代码重构,或开始新加功能。

4.对团队带来的提升

4.1 被动接收需求到主动应对

 需求分析阶段,运用5W原则。剖析需求的合理性,能主动把控项目的变化方向。解决“挑战三”对需求价值辨别和改善了“挑战四”的把控业务发展变化方向。

4.2 降低沟通成本

运用统一语言思想沟通,降低“挑战五”的各个环节的协作成本。

4.3 架构设计提升

通过设计元模型的子领域模型、限界上下文合理拆解代码规模。通过DDD的分层思想,隔离业务逻辑与技术维度复杂度,清晰代码结构。同时项目采用菱形对称结构,通过南北向网关与外部交互,避免了模块的网状情况滋生。解决了“挑战二”问题和降低了“挑战一”复杂度问题。

4.4 技术实现提升

团队在开发业务功能时,会考虑需求放到那个限界合理。实现过程会考虑放到领域层还是业务服务层,功能的实现上采用贫血模型还是充血。

4.5 文档规范提升

文档规范上,引入服务规约机制。既能作为梳理需求的工具,又能作为单测的依据。同时还为后期提供了服务说明的文档。

4.6 代码实现提升

代码实现上,从架构到编码实现、命名,形成了一套有标注的规范。

总的来说,该模式下,团队的思维方式发生了转变。通过应用各类元模型,来应对从需求分析到系统架构、代码实现不同环节带来的挑战。

 5.理论到实战遇到的冲突 

5.1 贫血模型 PK 充血模型

 贫血模型:通俗来说,就是domain object只有属性的getter/setter方法的纯数据类,业务逻辑和应用逻辑都放到服务层中,这种模型下的domain object被Martin Fowler称之为“贫血的domain object”。

充血模型:反之,充血模型中不仅包含了对象的属性,还包含了对象的行为,包括业务逻辑。

从面向对象角度分析,对象是包含属性和行为的,理应是使用充血模型,并且DDD原则上也是建议采用充血模型。但落地到具体开发现状,即便是贫血模型有很多问题,但业内存在这么多年、运用这么普遍,总归是有其存在的价值。加上JAVA应用大部分采用Mybatis技术栈,很多对象是插件自动生成的贫血实体。所以问题来了,采用充血模型意味着一部分便利工具的废弃。这个问题团队内分歧比较大。最终我们的方式是这部分不做硬性标准,但建议使用充血模式。

5.2 严格遵守数据转换约束  

PK 精简提效的外部数据直接使用

在DDD的思想中,为了确保领域服务的可靠性。要求领域服务依赖的数据为领域内的实体、聚合数据,不允许直接使用外部的消息锲约数据。对应到菱形对称架构的南北向网关获取数据的转换,会带来额外的工作量。有团队同学建议某些相对稳定的结构可以不遵守该原则,理由是能提高开发速度,且认为可能90%的数据都是如数据库这类结构较为稳定的资源。但最终团队内还是严格要求遵守该指导思想。

5.3 缓存处理  

允许共享 PK 限界隔离

同一系统不同限界中缓存处理:允许共享 PK 各限界隔离。

就当时场景来看,允许共享短期内能减少部分工作量、节约资源等优势。但之所以要划分限界,就是为了拆解关系防止过大。这里给到的建议是,首先考虑共用数据的服务是不是合并为一个限界比较合理。如果不能合并,必须隔离数据。

5.4 服务规约对照需求的前端 PK 后端

 指导理论思想很美好,需求分析时要求屏蔽技术实现思维。但终归是要落地到技术栈的,落地到技术实现时就会受技术实现的干扰。当时比较突出的一个问题,功能的实现可以放到前端,也可以后端服务实现。

举例一:需求要求“id+名字”组合展示,但是后端接口返回的id、名字两个字段,实际前端技术栈来组合,那面向前端与后端的服务规约不一致。

举例二:需求要求验证参数非空。在一些内部系统中,我们团队技术都是前后端全栈工程师,分工按需求模块开发。往往不会特别严谨到两端都做验证。也导致服务规约面向哪端有冲突。

我们最终的取舍:团队采用面向后端服务层面。但同时做一些改进,如验证这类功能转移到接口层面来实现。

5.5 谁来确保服务规约编写是否正确

产品PK 技术

 最开始阶段理想状态是由需求侧产品来核验,本着谁的需求谁确认原则。但由于存在4.4的差异问题,我们实际落地是由技术负责人来审核。

6.未来在DDD应用方面的

改进和总结

DDD的应用,团队目前做到了从架构和规范上面进行落地。但一些细节如:聚合类、实体、值对象这些设计,并没有特别精细。后期会进一步推进在这些细粒度上面的改进。同时,对一些在用的老项目,按照DDD思想进行改造重构。

有人认为应用DDD会降低开发效率,这个也是很多团队的一个顾虑。我们是这么看待这个问题的,应用DDD的场景是解决复杂性业务问题的,确实是会增加代码量。但不等于降低开发效率。清晰的架构结构、聚合的领域服务和规范的标准,对后期需求升级、代码维护、复杂度控制带来的收益,远大于投入。并且,软件行业给出的数据,80%的时间是在需求分析和设计,开发时间只占到20%。因此这部分损耗不是重点。

最后,陈述一下使用DDD的感受。DDD各种元模型种类繁多,大家可以根据业务面临的痛点有目的来学习和采用。在实际的业务环境中,我们的领域模型或多或少的都有一定的“特殊性”,如果100%的要符合DDD规范可能成本会比较高,所以最主要的是理解DDD思想,最终选择合适自身业务的方案。

作者简介

图片

李晓华 

■ 经销商事业部-经销商技术部。

■ 2016年加入汽车之家,目前任职于经销商数据架构组团队,负责电话机器人项目。

版权声明:本文内容转自互联网,本文观点仅代表作者本人。本站仅提供信息存储空间服务,所有权归原作者所有。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至1393616908@qq.com 举报,一经查实,本站将立刻删除。

(0)

相关推荐

发表回复

登录后才能评论