本文书接上回《图穷匕见-所有反DDD模式都是垃圾》，关注公众号（老肖想当外语大佬）获取信息：
最新文章更新；
DDD框架源码（.NET、Java双平台）；
加群畅聊，建模分析、技术实现交流；
视频和直播在B站。
背景
我在与开发者交流关于DDD的建模思路时，往往会遇到一个难题，就是不少经验丰富的开发者，总是带着技术的思维来理解业务，ta的大脑里无法纯粹地勾勒出一个边界明确的代表业务实体的形象。其中最明显的一个现象，就是习惯性地用关系数据库中的“关系”，来映射业务模型之间的关系，一旦带着“关系”来思考，那么“边界”就很难再有一席之地。而对于没有太多“关系数据库”经验的开发者，反倒很容易理解什么叫“边界明确”。
关系型数据库的三范式
这里我们先列出来关系型数据库的三范式定义：
- 第一范式（1NF）：确保每列的值都是原子性的，即每列的值不可再分。
- 第二范式（2NF）：在满足第一范式的基础上，确保表中的每一列都完全依赖于主键，而不是部分依赖。
- 第三范式（3NF）：在满足第二范式的基础上，确保表中的每一列都不依赖于非主键列，即消除传递依赖。
更通俗地说：
- 第一范式（1NF）：每个字段只能存储一个值，不能有重复的列。
- 第二范式（2NF）：在满足第一范式的基础上，所有非主键字段必须完全依赖于主键，而不能只依赖于主键的一部分。
- 第三范式（3NF）：在满足第二范式的基础上，非主键字段之间不能有依赖关系，必须直接依赖于主键。
而满足三范式的几个关键目的：
- 消除数据冗余：通过确保每个数据项在数据库中只存储一次，减少数据重复，节省存储空间。
- 提高数据一致性：减少数据冗余后，数据更新时只需修改一个地方，避免数据不一致的问题。
- 简化数据维护：通过规范化设计，减少数据异常和复杂的维护操作，使数据库结构更清晰，易于管理和扩展。
DDD思维 vs 三范式思维
假设我们在设计一个包含用户、角色、部门要素的系统，如果我们基于关系数据库的思维，那么设计出来的效果大概率类似下图：
假如我们设计一个系统，完全满足关系型数据库的三范式，那么可以推论出来，基本上整个系统的所有实体之间都会直接或者间接地产生“关系”，画出来的图也会像一张蜘蛛网一样错综复杂，这与DDD的理念正好相反。
因此，从这个角度来说“关系型数据库三范式的模式是一种反DDD模式”。
而如果我们使用DDD的思维，那么“连线意味着它们就是一个整体”，要把边界给明确出来，就需要消除连线，那么设计出来的图，大概率是下面的样子：
当然你一定会有疑问，用户和角色之间客观上是存在关系的呀，你把连线移除，那么这个关系就无法表达了，上面的图并不能反映完整的设计，实际上，如果我们把“用户聚合”的细节图展开，你就会发现，我们把“关系”放置到了“用户聚合内部”，需要注意的是这里多出来了一个叫“用户角色”的实体，它与“角色聚合”不是同一个概念。
到这里，我想你也能发现DDD的思维有一些特征：
-
聚合之间不连线（join），保持边界明确
-
聚合内部满足关系型数据库三范式
-
为了实现聚合之间不连线（join），会产生一些“冗余”实体
代价与收益
假如我们使用DDD的模式来设计系统，代价是数据会一定程度上的“冗余”，这些冗余的实体数据，需要通过“事件驱动”的方式保持一致性，而收益是系统被明确地划分成了多个边界明确的“领域”，复杂度就像“杂物”一样被收纳在了一个个“收纳箱”。
此外，关于“冗余数据”，我们是从“关系型数据库”的视角来看待的，如果用DDD的视角来看，前面模型图中的“用户角色”是“用户聚合”客观上存在的属性，因此它不是冗余。你看，我们一旦切换到DDD的视角，会发现事情变得很自然了。
现实世界到处是冗余
如果上面的例子，你仍然觉得没有说服力，那么可以观察一下现实世界的状况，你会发现信息冗余的现象是普遍存在的，比如我的手机通讯录，冗余了你的名字和手机号，因为“我的通讯录”就是客观上“我”的属性，现实世界到处是类似的例子。
结论
如果你期望尽快地走进DDD的世界，那么在分析需求和设计模型时，一定要尽可能先忘记关系数据库和三范式的存在，哪怕你要应用三范式，也应该仅仅将它应用在你的模型的内部，千万不要用它来表达“聚合”之间的关系，因为，“聚合”是独立的有明确边界的。
