翟志军

这就是领域驱动设计(DDD)的作用?

面对需求,我们首先想到的是什么

在家电IoT这个领域里,通常都会需要实现家电的分享。比如老婆分享家里的电饭煲给老公,让老公控制电饭煲。

拿到这样一个需求,通常大脑里想到的就是增加一张家电分享表来实现:

appliance_user_shared
master_user_id
shared_user_id
appliance_id

然后再修改家电列表的实现,因为需要将别人分享给自己的家电也要能获取到。

同时,别忘记了,我们还要修改所有对于家电的操作的实现。比如业务规则中说明,家电的主人才能对家电的名称进行修改。

就这样,我们实现了用户对于一个家电的分享。这时的业务模型可以表示如下:

image.png

过不了多久,产品经理跟你说,如果一个用户家里有10个家电以上,一个个家电的分享,这种体验太糟糕了,我希望将一个家庭分享给其他人,这样,可以将家庭下所有的家庭一下子分享给另一个人了。

当然,我们同样可以将这个需求,看作是添加一个家庭分享表,再修改一下家电列表、家电名称修改、家电控制……这是A方案。

A方案的领域模型表示如下:

image.png

但是,我们还有一个B方案。

当我们仔细思考时,我们似乎掉进了产品经理挖的坑:产品觉得通过增加一个“分享家庭”的概念来实现多个家电的分享。

事实上,我们服务器端实现并不一定需要这样做。前端APP可以有一个家电分享的操作界面,但是,服务器在实现这个web api时,只需要在找到这个家庭下的所有家电,然后重用原来单家电分享的概念了,就可以了。

这样做,就非常符合软件设计的开闭原则:对扩展开放,对修改关闭。

基于B方案,我们不需要对家电列表等功能进行修改。同时,你还会发现,某天产品经理抽风,觉得一次性分享所有的家电不好,如果能在一个家庭基础下实现部分家电分享的功能,是不是更好?A方案就头大了。而B方案可以很轻松的应对。

B方案的领域模型表示如下:

image.png

说回来,我们应该警惕产品经理或需求人员帮我们做软件设计。

面对需求时,我们的大脑里,第一想到的是数据库表如何设计、如何实现改动最小、是使用微服务呢,还是使用七边形架构……这类技术问题时,我们的设计是技术驱动设计的。

如果我们大脑里第一思考的是什么单家电分享、家庭分享和单家电分享之间是什么关系……这类领域问题,然后基于这些思考,建立一个领域相关的知识体系——以领域模型为体现。如果我们的软件是基于此领域模型进行设计,就是:领域模型驱动软件设计。

按《领域驱动设计》中,作者所说的:

领域驱动设计是一种思维方式,也是一组优先任务。

领域建模

要搞清楚,什么是领域建模,就必须搞清楚什么是软件的核心。

我们来看看《DDD》前言里所写的:

一些设计因素是技术上的。软件的网络、数据库和其他技术方面的设计耗费了人们大量的精力。很多书籍都介绍过如何解决这些问题。大批开发人员很注意培养自己的技术,并紧跟每一次技术进步。

然而很多应用程序最主要的复杂性并不在技术上,而是来自领域本身、用户的活动或业务。当这种领域复杂性在设计中没有得到解决时,基础技术的构思再好也是无济于事。成功的设计必须系统地考虑软件的这个核心方面。

这个核心方面指的就是领域知识。

而领域建模就是消化吸收大量知识(领域相关),最后产生一个反映深层次领域知识并聚集于关键概念的模型。这也就是领域驱动设计的实质。

上文中,关于家电分享的例子,从A方案到B方案,实际上就是随着我们对领域知识的理解更深入,领域建模的一个过程。

小结

就如《DDD》作者所言:很多因素可能会导致项目偏离轨道,如官僚主义、目标不清、资源缺乏,等等。但是真正决定软件复杂性的是设计方法。当复杂性失去控制时,开发人员就无法很好的理解软件,因此无法轻易、安全地更改和扩展它。

领域驱动设计这种思维方式,再加上一整套的设计实践、技术和原则,就能帮助我们控制真正的复杂性。这就是领域驱动设计的作用。

而这种思维要求我们在面对领域问题时,优先考虑的是领域问题,而不是技术问题。

注意,这并不是说我们不考虑技术如何实现。这是优先级问题。

最后,以上举的例子并不是最终的模型。因为家电分享这个概念并不是最根本的概念。更根本概念是家电的权限。这是一个更层次的领域模型:

image.png

End


为你的收获买单