领域驱动设计DDD你也可以!| 第8期

2023-02-23 17:12:13
践行者
原创
568
摘要:践行者第8期,我们和易盛信息副总经理张廷利,易盛信息场外项目负责人李龙谱,一起畅聊了他们是如何从0开始进行DDD的!


践行者第8期,我们和易盛信息副总经理张廷利,易盛信息场外项目负责人李龙谱,一起畅聊了他们是如何从0开始进行DDD的!

一、领域驱动设计DDD

易盛信息副总经理张廷利和场外项目负责人李龙谱,在聊天中强调,DDD 是一个密码,是指导我们整个实践的一套理论,是一个很好的关于结构化思考的示例,能够把我们的业务都结构化,通过结构化的分层,方便我们进行上层业务的组装,上层业务的组装其实就是敏捷式的业务创新。

通过DDD,我们会在一开始把需求描述清楚,按照业务流程把这些规则描述清楚,通过我们的技术构造,让系统运转起来,这就形成了一个通路。最终应该是我们要达到的目的,应该是支持业务人员自由创作的这么一个自由创作。

总而言之,DDD其实这整个是一个结构化思维,它一方面是把代码结构化了,另一方面是把业务也结构化了。结构化的结果就是把所有的这些东西,拆分成类似乐高一样的模块,这样我们业务人员就像玩乐高积木一样,可以用它去拼一个轮船、拼一个汽车。我业务人员可以随便拼,并且模块之间也是相对稳定的,每一个模块既可以被业务人员理解,也可以被研发人员理解。这样我们就在业务和研发之间建立一个非常好的桥梁,让工作变得很简单。

二、直播问答实录

1.你们在推敏捷吗?DDD和敏捷应如何结合?

其实没有刻意地去做敏捷,但我们交付的版本速度比较敏捷,基本一两周交付一个版本。实际上,当我们把业务模型想清楚后,对版本规划能更清晰,便可以知道短期内我们需要做什么事情,需要如何发版本、如何集成以及如何测试……

我们没有专门的敏捷教练,除DDD外,我们也很关注CI、CD,实现快速集成、快速部署、快速测试。虽然我们没有固定的迭代周期,但也差不多一两周一个版本发布,包括测试人员也是在形成业务架构模型的时候参与进来的。


2.DDD概念和微服务集群有什么区别?

DDD这套理论能够帮助划分微服务的边界。它们不是能够进行比较的概念,DDD是一种手段。


3.有没有找亚马逊的顾问现场一起做呢?

没有的。不过实践DDD,大家可以看看张逸老师的书,书里介绍得很清楚,并且给出的是一套如何实践的方法。非常推荐大家看一看。


4.领域驱动设计的目的是什么?

这个问题的答案在Eric Evans书的副标题中能得到解答,它叫《软件核心复杂性应对之道》。软件核心复杂性其实指的是业务复杂性,包括业务变动引起的难以预测的复杂性。

5.谁来拆分业务,是需求分析人员吗?

是业务和技术负责人一起来拆。

6.你们做事件风暴工作坊之类的实践吗?

之前尝试过,但后来发现这类实践其实是需求分析的工具,它可能更开放一点,需要有业务专家的参与,包括技术、开发、测试等等。



我们可以用其他的手段代替这类实践,如传统的需求分析方法,我们可以从业务开始到结束的时间线出发,把整个业务线梳理清楚,逐渐在脑海中构建出一个模型,接着通过这一模型不断去推演所有的业务场景。有了业务模型后,才能反映到文档上、与别人交流,并最终反映到代码上。对于初学者来说,还是可以体验下事件风暴的,应该会有一些感触。

7.DDD就是业务架构与技术架构相互映射对应统一的过程吗?

在DDD中,业务模型和技术模型是一个模型。同时,这是DDD中的一个关键点,并非全部。

8.需要让业务、技术人员都了解DDD模型,应先在业务的角度考虑,是这样吗?

让业务、技术人员都了解DDD模型是一个很关键的部分。而站在什么角度考虑这一问题,其实整体业务架构还是会偏业务多一些,同时也会从一些技术实现的角度进行考虑。这里要注意的是,从技术角度考虑并不是考虑到代码的维度,而是从技术角度看能否实现。因为整体业务模型其实还是业务,和技术细节没有关系。

9.能推荐一本书吗?

大家可以看整洁代码架构方面的书,还可以看付晓岩老师写的关于银行数字化转型、企业架构、聚合架构的书。刚才说的映射过程,《聚合架构》里也已经说明了,比如如何分析业务过程,如何把公共组件抽出来等等。书中提到DDD是一种做领域抽象的方法,大家可以去看一下。

其实很多书都是讲原则理论,我们可以先了解这些书的内容,最终还是需要先行动,在过程中找到解决方案。

10.好的领域模型带来的价值是巨大的,那用什么方法才能得到好的领域模型呢?

Evans大概 2014 年的时候,画了一张叫做“Model Exploration Whirlpool”的图,这是由三个圈组成的图:第一个圈指业务场景(通过用户故事表达),第二个圈指领域模型,第三个圈指代码。

(图源:https://www.domainlanguage.com/ddd/whirlpool)

Evans用这张图来解释我们应如何构建模型。当我们拿到一个新的需求,首先要把业务场景表达出来,接着看我们的模型是否能支撑业务场景。如果能支撑那么模型就是合适的,如果不能支撑就需要进行调整,调整后再落实到代码层面。


其实这就像一个洗衣机(惠而浦洗衣机),把这三个东西在里面不停地搅和,慢慢找到更适合的模型。一个好的模型能够像洗衣机一样,通过持续不断地动态过程反复提炼出来。

11.你们做度量吗?有已梳理好的研发流程吗?

我们的流程在 CI、CD 层面已经工具化、自动化了,但在度量层面上还需要再加强。今年准备趁着DevOps优化机会,在度量方面再加强一下。我认为度量能够帮助我们做管理,但是不能指望靠度量管理。

关于度量,有一些比较有挑战性的问题,如果不度量的话,领导怎么知道谁在偷懒?这些其实可以靠生产指标来判断,比如需求响应速度、生产的故障率等等。其实基于DDD的很多开发是固定的,我更建议看到实效后,再开始度量。因为度量有成本,并且度量一般都是和自己比,不应该是团队之间比。最好的方式是先让自己的工作方法成熟定型,然后通过度量来进行不断地优化。

12.有没有好的原子服务模块切割好的方法或者思路?

首先,经验很重要,你需要对这个领域有一定的认识,另外要对现成的需求分析,包括事件风暴这些方法论。并且你需要不断地反复地去尝试,去思考这个事情。

原子服务其实又回到结构化思考了,结构化思考里有个MECE原则,就是关于相对独立,穷举的概念。我们可以去找到这种原子服务模块,但最后进行组装后,他还需要彼此聚合,因为划分的很细时,原子模块是不好用的,它必须得结合成一系列的概念。

DDD里会有隐喻的概念,比如在极限编程里有提出隐喻的方法,可以将它用在模型上,去诠释那些稍微大一些的概念,在这个层面上讲一个自成体系的模块,它就是一个原子服务,但这也是千人千面的。你可以根据你自己的理解去做,中间是有弹性的,并不是有完整的非黑即白的结果,它是根据你的需要来进行组合。

另外一个方面就是这种原子服务组装出来之后,我们可能还没有做微服务,但是我们的应用内部已经做了隔离切分,就像DDD里讲大泥球反模式,虽然在一个大进程里,我们把它切分的更条理化,它可能和这种微服务,没有强关联的关系。只是你去治理你的知识结构,由知识结构逐渐衍生出来一些系统和业务规则,就是业务层上的一些组装。

如果说到好的经验和方法,我推荐前面提到的“三个圈”方法,就这三个圈不停地在搅和,你就慢慢地能找到一些切分的方法,这需要自己心里有把尺子,自己觉得合适就好。它没有一个统一固定的标准。


    发表评论
    通过审核后显示您的意见