DDD -- 领域驱动设计 -- 到底啥叫“建模”?

在软件领域,说到“建模”,就会蹦出各种各样的名词:面向对象建模、业务建模、领域建模、UML建模、ER实体建模、4色建模法、DCI。。

这些方法之间有区别,又互相有交叉;有的比较新,有的是以前的老方法。混在一起,很容易让人”云山雾罩“,讲来讲去,不知所云。

然后学的人,很容易照葫芦画瓢,画各种看上去高大上的图:业务流程图、类图、交互图。。但仔细一深究,又是到处漏洞,图不能完全表达义务语义,“华而不实”。

本文希望跳出这些方法论的框框,去思考一个根本性的问题:建模的本质到底是什么?

本人新书出版,对技术感兴趣的朋友请关注:
DDD -- 领域驱动设计 -- 到底啥叫“建模”?_第1张图片
https://mp.weixin.qq.com/s/uq2cw2Lgf-s4nPHJ4WH4aw

建模的本质 – 重要东西“显性化”

很多时候你会遇到这样的情况:一个函数写了几百行,里面的if-else写了一大堆,计算各种业务规则。另一个人接手之后,分析了好几天,才把业务逻辑彻底理清楚。

这个问题从表面来看,是代码写的不规范,要重构,把一个几百行的函数拆成一个个小的函数。从根本上来讲,就是“重要逻辑”隐藏在代码里面,没有“显性”的表达出来。

这只是一个函数,推而广之,到类、到模块、到系统,是同样的道理,比如:

业务流程隐藏在多个对象的复杂调用关系里面;
某个业务核心概念没有提取出来,其职责分摊到了其他几个实体里面;
系统耦合,职责边界不清。。。

所以,个人观点:建模的本质就是把“重要的东西进行显性化,并进而把这些显性化的构造块,互相串联起来,组成一个体系“。

重要的东西 – 构造块

那么哪些东西是”重要“的呢? 比如领域实体,比如某个业务流程(对应到DDD里面就是”领域服务“),比如某条重要的业务规则(对应到DDD里面就是Specification模式),比如复杂对象的创建过程(对应到DDD里面,就是工厂模式)。。

说白了,就是你要把你系统里面“重要的”东西挑出来,让它在“设计图纸”上可见,而不是分析完代码才能看出来!

显性化

重要的东西找到了,如何显性化呢,其实就是“命名”。名不正则言不顺,名字反映了职责,名字也让领域专家、架构师、程序员对“同一个东西”进行讨论,而不是“牛头不对马嘴”。

形成体系

找到了“重要的东西”,“命名成构造块”,接下来就是通过某种结构,把这些“构造块”组装起来,成为一个整体。这就成了某种“方法论”!

建模的层次

不是说做业务分析才有建模,即使没有任何的业务建模,你就直接写一个超大函数,里面包含所有代码,这何尝不是一种“建模”呢?

只不过这种“建模”的构造块太小:加、减、乘、除,if-else,for,while。。这些就是这种“建模”方法的构造块,并且这种方法,当程序员的都尤为擅长。

再远一步,我在这写文章和你沟通,何尝不是一种“建模”呢?这里建模的“构造块”就是那常用的3000多个汉字和标点符号,构造规则就是”主谓宾定状补“。

通过上面的分析,我总结出如下的建模范式:
DDD -- 领域驱动设计 -- 到底啥叫“建模”?_第2张图片

把这个范式,应用到不同的粒度,得到下面的图示
DDD -- 领域驱动设计 -- 到底啥叫“建模”?_第3张图片

(1) 自然语言建模
构造块:常用的那几千个汉字(或者英语的10万单词)。。
语法规则:主谓宾定状补

(2)计算机语言建模
构造块:加/减/乘/除,if-else, for, while…
语法规则:程序员最熟悉,此处就不说了

(3)过程建模
构造块:函数
语法规则:整个系统描述成一个个过程,每个过程通过函数的层层调用组成

(4)对象建模
构造块:对象
语法规则: 整个系统描述成对象与对象之间的关系

(5) DDD领域建模
构造块:实体/值对象/领域服务/领域事件/聚合根/工厂/仓库/限界上下文
语法规则:就是“构造块”之间的联系(不是很明显,这个需要深入研究。也正是DDD难掌握的地方)

最后

本文试图跳出各种软件方法论的“框框”,从一个旁观者角度去审视“建模”这个最最基本的东西,希望以此成为大家理解DDD的一个线索。

你可能感兴趣的:(DDD领域驱动设计)