反DDD模式之关系型数据库

程序员有二十年 2024-09-18 10:30:48
背景

我在与开发者交流关于DDD的建模思路时,往往会遇到一个难题,就是不少经验丰富的开发者,总是带着技术的思维来理解业务,ta的大脑里无法纯粹地勾勒出一个边界明确的代表业务实体的形象。其中最明显的一个现象,就是习惯性地用关系数据库中的“关系”,来映射业务模型之间的关系,一旦带着“关系”来思考,那么“边界”就很难再有一席之地。而对于没有太多“关系数据库”经验的开发者,反倒很容易理解什么叫“边界明确”。

关系型数据库的三范式

这里我们先列出来关系型数据库的三范式定义:

第一范式(1NF):确保每列的值都是原子性的,即每列的值不可再分。

第二范式(2NF):在满足第一范式的基础上,确保表中的每一列都完全依赖于主键,而不是部分依赖。

第三范式(3NF):在满足第二范式的基础上,确保表中的每一列都不依赖于非主键列,即消除传递依赖。

更通俗地说:

第一范式(1NF):每个字段只能存储一个值,不能有重复的列。

第二范式(2NF):在满足第一范式的基础上,所有非主键字段必须完全依赖于主键,而不能只依赖于主键的一部分。

第三范式(3NF):在满足第二范式的基础上,非主键字段之间不能有依赖关系,必须直接依赖于主键。

而满足三范式的几个关键目的:

消除数据冗余:通过确保每个数据项在数据库中只存储一次,减少数据重复,节省存储空间。

提高数据一致性:减少数据冗余后,数据更新时只需修改一个地方,避免数据不一致的问题。

简化数据维护:通过规范化设计,减少数据异常和复杂的维护操作,使数据库结构更清晰,易于管理和扩展。

DDD思维 vs 三范式思维

假设我们在设计一个包含用户、角色、部门要素的系统,如果我们基于关系数据库的思维,那么设计出来的效果大概率类似下图:

假如我们设计一个系统,完全满足关系型数据库的三范式,那么可以推论出来,基本上整个系统的所有实体之间都会直接或者间接地产生“关系”,画出来的图也会像一张蜘蛛网一样错综复杂,这与DDD的理念正好相反。

因此,从这个角度来说“关系型数据库三范式的模式是一种反DDD模式”。

而如果我们使用DDD的思维,那么“连线意味着它们就是一个整体”,要把边界给明确出来,就需要消除连线,那么设计出来的图,大概率是下面的样子:

当然你一定会有疑问,用户和角色之间客观上是存在关系的呀,你把连线移除,那么这个关系就无法表达了,上面的图并不能反映完整的设计,实际上,如果我们把“用户聚合”的细节图展开,你就会发现,我们把“关系”放置到了“用户聚合内部”,需要注意的是这里多出来了一个叫“用户角色”的实体,它与“角色聚合”不是同一个概念。

到这里,我想你也能发现DDD的思维有一些特征:

聚合之间不连线(join),保持边界明确

聚合内部满足关系型数据库三范式

为了实现聚合之间不连线(join),会产生一些“冗余”实体

代价与收益

假如我们使用DDD的模式来设计系统,代价是数据会一定程度上的“冗余”,这些冗余的实体数据,需要通过“事件驱动”的方式保持一致性,而收益是系统被明确地划分成了多个边界明确的“领域”,复杂度就像“杂物”一样被收纳在了一个个“收纳箱”。

此外,关于“冗余数据”,我们是从“关系型数据库”的视角来看待的,如果用DDD的视角来看,前面模型图中的“用户角色”是“用户聚合”客观上存在的属性,因此它不是冗余。你看,我们一旦切换到DDD的视角,会发现事情变得很自然了。

现实世界到处是冗余

如果上面的例子,你仍然觉得没有说服力,那么可以观察一下现实世界的状况,你会发现信息冗余的现象是普遍存在的,比如我的手机通讯录,冗余了你的名字和手机号,因为“我的通讯录”就是客观上“我”的属性,现实世界到处是类似的例子。

结论

如果你期望尽快地走进DDD的世界,那么在分析需求和设计模型时,一定要尽可能先忘记关系数据库和三范式的存在,哪怕你要应用三范式,也应该仅仅将它应用在你的模型的内部,千万不要用它来表达“聚合”之间的关系,因为,“聚合”是独立的有明确边界的。

0 阅读:11

程序员有二十年

简介:感谢大家的关注