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

如何解决事件溯源需要多少个数据库或表？

我正在尝试使用事件源、ddd 和 cqrs。 我无法理解我必须创建两个数据库（或表）（1-json 2-normalize 数据库）或一个数据库（只是 json） 而且，如果我创建了两个数据库（或表），我是否必须在一个事务中将数据库（json 和 normalize）中的数据保存为原子？ 最好的问候

解决方法

我不明白我必须创建两个数据库（或表）（1-json 2-normalize 数据库）或一个数据库（只是 json）

只需要一个活动商店就可以了，别无其他。

然而，“过得去”并不一定令人愉快。通常，事件存储非常擅长“追加新信息”，但不是特别擅长“查询”。因此，通常的答案是部署流程，将信息从您的事件存储复制到具有更好查询支持的内容。

我是否必须将数据库中的数据（json 和规范化）保存为一个事务中的原子数据？

仅更新事件存储，然后调用流程将信息从事件存储复制到您的查询支持是一种常见模式。当然，这也意味着您的查询最终可能会显示过时/过时的信息（这是截至五分钟前您的问题的答案）。

如果您将查询友好数据模型与事件存储（例如，同一关系数据库中的表）一起存储，那么您可以安排至少一些对查询友好模型的更新与事件同步。

换句话说，您需要权衡取舍，而不是到处使用的单一模式。

,

DDD

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

CQRS

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

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

事件溯源

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

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

因此，文档数据库是事件存储的绝佳选择，因为单个文档表示给定聚合的事件流。但是，如果您想将事件流存储在 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 等）来编写使用它们的代码，那么您可以将其称为“投影” .它将处于一种形状的数据“投影”为适合不同目的的另一种形状。结果是“读取存储”，然后您可以根据需要进行查询。