读模型与数据库的设计

更新: 3/15/2025 字数: 0 字时长: 0 分钟

虽然在我们的DDD总体设计中是不大关心读模型的，但是读模型确实我们在软件模型中不可获取的一部分。

我们这里来重点讨论一下读模型与数据库的设计

读模型

在之前我们提到CQRS的时候说过，读模型更加关心的是读这一操作，这个话究竟是如何体现的呢？

如果小伙伴做过不使用CQRS的表的话，可能会发现一个问题，数据库中有的字段几乎是不反馈给用户的，只是单纯的用于业务使用（比如一个抽奖系统，我们的数据库会记录一个抽奖的概率值，但我们肯定是不会反馈这个给用户的），这往往是我们的实体

同样的，我们的数据库中还存在一种几乎不会与逻辑相关，只是单纯的修改的数据（比如用户名，几乎不会做一个逻辑关系），这就是我们的读模型

于是就会产生一系列建议，“通过冗余字段来提高查询的效率”，“一次查询不能联三张以上的表”。

那么这时就会有一种更加”狠“的想法——我为什么不能直接查询和处理逻辑的数据分开成为两张表呢？

这也就是我们CQRS的一个最简单的理解方式

回顾完了读模型和CQRS，我们这里再来讨论一下数据库设计。

首先，我必须强调一点：DDD不（直接）关心数据库设计

我们在做整个时间风暴建模的过程中其实是不关心数据库是如何搭建的，反而是通过我们风暴建模之后的风暴图去思考如何设计数据库

我们往往会为Command和Read分开建两张表，而Command的表对应的应该是Aggregate的数据，Read就是我们的读模型的数据啦

有时我们读模型是不经过业务直接去读取的，这种就属于CQ完全分离，两者互不联系，还有一种就是我们的数据需要完成经过业务之后再修改，这种可能就需要我们现在Command相关的DDD中去完成业务，然后再去通知读模型去修改

还有一种情况是Command和Query冗余了相同字段，这时Command自身修改完后就需要对Query的表再进行修改