只读侧的事件源/ CQRS数据库约束

Question

我们公司希望为我们的金融系统实施Event Sourcing / CQRS。

对于只读模型，我们应该应用数据库约束吗？ 我知道约束不应该在Write事件存储端。 只读模型方面怎么样？

，包括：

• 唯一约束
• 外键约束
• 检查约束
• 默认约束
• 参考诚信

Answer 1

  

对于只读模型，我们应该应用数据库约束吗？我知道约束不应该在Write事件存储端。只读模型方面怎么样？

这可能没有做任何有用的事情。

从根本上说，有两种情况。一个是读模型中的约束与域模型的约束不一致。如果域模型是权限，则读取模型错误。

另一个是约束是对齐的，但是读取模型认为约束已被违反，因为它对所发生的事情有不完整的看法。 IE，域模型发出事件[A,B,C,D]，但读模型现在只看到[A,B,C]。

现在，读取模型中的数据应该被理解为陈旧;因此，只有在域的新的，一致的视图可用时才更新读取模型并不合理。

但即便如此，它仍然不清楚是否应该由数据存储或填充商店的事件消费者强制执行约束。

我不确定数据库限制会在正常操作期间为您带来什么。

他们可能在特殊操作期间成为有用的指南;如果有人试图通过手动修改读取模型＆＃34;然后在数据库中拥有约束的冗余副本可能会防止数据输入错误。 （读取模型的通常恢复过程是您销毁缓存副本并重建它;但如果需要花费相当多的时间，则修复现有副本可能会更好地为您的SLO提供服务。副本可用。）

Answer 2

我在读模型上使用数据库约束。

• FK帮助级联删除以及告诉你（如果你得到一个例外）你的应用程序中有一些案例最终会出现一个不一致的状态（也许应用程序在过去的某个时刻崩溃并且读取的模型不是没有更新）。耐用的服务巴士减轻了这一点。
• 默认值只是默认值，我没有看到问题。
• 我使用唯一约束来表示幂等性，并在发生违规时忽略。

您可以看到，您可以将db约束用于多种用途，并且它们都与您在写入模型中使用的业务约束无关。