事件溯源需要多少数据库或表？

Question

我正在尝试使用事件源、ddd 和 cqrs。我不明白我必须创建两个数据库（或表）（1-json 2-标准化数据库）或一个数据库（只是json）而且如果我创建了两个数据库（或表），我必须保存数据在数据库（json 和规范化）中是否作为一个事务中的原子？此致

Answer 1

DDD

我们在这里假设您完全理解 DDD 的使用及其含义。具体与事件溯源相关，这是定义聚合边界和成为其状态的事件的问题。

连续QRS

我们再次假设您完全理解其中的含义。CQRS 仅仅允许您在垂直切片（即从 UI 到数据库）中编写代码，以便与处理“查询”的代码分开处理“命令”。就这样。虽然您确实可以通过将数据存储在“读取模型”中来更进一步，该模型甚至可能位于不同的数据库中，更不用说表了，但这并不是实现 CQRS 的要求。

由于 CQRS 与事件溯源相关 - 它非常适合，因为您在事件溯源中最终得到的数据模型不利于复杂查询。它通常仅限于“通过 ID 获取聚合”。因此，典型的方法是通过“投影”以更适合查询和加载到 UI 的其他方式存储数据。

事件溯源

如果您以这样一种方式实现域模型，即聚合处理的每个命令（即用户执行的每个用例/任务）都会生成一个或多个事件，那么事件溯源就是您存储这些事件列表的原则以仅追加的方式针对聚合的 ID，而不是在命令成功处理后存储聚合的快照。

要从事件存储加载聚合，您需要加载所有以前的事件，并在聚合对象的内存中重播它们，而不是加载单个行/文档作为快照/备忘录。

因此，文档数据库是事件存储的绝佳选择，因为单个文档代表给定聚合的事件流。但是，如果您想在 SQL 中存储事件流，那没问题，但您可以将其存储在两个表中：

create table Aggregate (Id int not null...);
create table AggregateEvent(AggregateId int not null FK..., Version int not null, eventBody nvarchar(max));

实际的事件正文通常是事件本身，序列化为 JSON 等文本格式。

预测和读取存储

如果您获取通过聚合处理命令生成的事件，并编写通过写入单独的数据存储（SQL、预先计算的 ViewModel 等）来使用它们的代码，那么您可以将其称为“投影”。它将一种形状的数据“投影”成另一种适合不同目的的形状。结果是一个“读取存储”，您可以根据需要进行查询。