SQL 中的域事件存储...使用 JSON 序列化？
Domain event storage in SQL... use JSON serialization?
我正在考虑重构一个现有的 code-base，然后再与我们的第一个客户一起发布，我真的不喜欢当前的域事件存储结构，我正试图来想出一种在 RDB tables.
中存储许多非常不同的事件的好方法
架构：
- 网络应用程序
- Java
- Spring 4
- Spring JDBC
- MSSQL
详情：
- 40+ 个不同的事件，每个都与聚合根或其 child 元素之一相关。
- 存储事件的详细信息，但不存储 object 状态（因此没有 CQRS 事件源）
- 事件仅用于报告
- 报告由 java object 提供。 IE。报告不 运行 直接来自 SQL.
目前事件存储在每个限界上下文的单个事件 table 中。为了保存所有不同的事件类型和数据，table 架构看起来像这样
event_id long,
event_type varchar,
event_time datetime,
context_1_key varchar,
context_1_val varchar,
context_2_key varchar,
context_2_val varchar,
context_3_key varchar,
...重复 10 次...
所以，例如（order=聚合根，item=child of order）：
event_type=ITEM_OPEN
context_1_key=ORDER_ID
context_1_value=1000
context_2_key=ITEM_ID
context_2_value=2000
不，我不喜欢，不，我不应该为此负责。
问题：
- context_1_xxx 领域脆弱且难以maintain/troubleshoot/expand
- 将所有东西都塞进一个 table 将是一个性能问题（即使报告对性能不敏感）
- 事件链接到域object；它们不存储 object 的状态。例如。如果项目被删除，记录的事件是无用的
我的直觉告诉我，创建 40 个不同的 tables 并为每个事件设置唯一的模式并不是答案。相反，我正在考虑序列化（JSON）要与事件数据一起保存的域 object(s) 的快照。
看来方便解决：
- 我们已经使用 Spring/Jackson 模块为 browser-based 客户端序列化 object。
- 团队非常适应table serialize/deserialize 流程，因此没有主要的学习曲线。
- 事件数据必须通过应用程序返回以生成报告，de-serializing 和 Jackson
会很容易
我能看到的唯一真正的缺点是：
- 无法使用基于 SQL 的第三方报告工具
- 无法在存储的 object(JSON)
的属性上索引 tables
我可以通过将事件存储进一步分解为几个不同的 table 来稍微缓解问题 #2。
我还缺少什么？是否有既定的 best-approach 来实现这一点？你是怎么做到的？
从 Greg Young 的 Building an Event Storage 开始。
Konrad Garus 描述了一个使用 PostgresSQL 的事件存储。
My gut tells me creating 40 different tables with schema unique to each event is not the answer.
可能不会。对于所有类型的事件，第一次剪辑应该是单个 table。您有一个用于事件数据的 blob（json 很好），还有一个用于事件 metadata 的类似 blob，然后是一堆用于提取正确排序的列事件的历史。
Instead I was thinking of serializing(JSON) a snapshot of the domain object(s) to be saved along with the event data.
这是一个奇怪的短语。 JSON 事件数据的表示？这就说得通了。
不过，"Snapshot" 让人大跌眼镜——您不需要事件数据的快照，因为事件是 immutable。您肯定不希望将状态快照（即汇总事件历史的结果）与事件本身混合在一起。
跟进：查看 GetEventStore .NET 客户端 writes and reads 事件历史记录可能会给您关于如何设计架构的更多想法。请注意，事件 data/metadata 正在作为 blob 处理。
我正在考虑重构一个现有的 code-base，然后再与我们的第一个客户一起发布，我真的不喜欢当前的域事件存储结构，我正试图来想出一种在 RDB tables.
中存储许多非常不同的事件的好方法架构：
- 网络应用程序
- Java
- Spring 4
- Spring JDBC
- MSSQL
详情：
- 40+ 个不同的事件，每个都与聚合根或其 child 元素之一相关。
- 存储事件的详细信息，但不存储 object 状态（因此没有 CQRS 事件源）
- 事件仅用于报告
- 报告由 java object 提供。 IE。报告不 运行 直接来自 SQL.
目前事件存储在每个限界上下文的单个事件 table 中。为了保存所有不同的事件类型和数据，table 架构看起来像这样
event_id long,
event_type varchar,
event_time datetime,
context_1_key varchar,
context_1_val varchar,
context_2_key varchar,
context_2_val varchar,
context_3_key varchar,
...重复 10 次...
所以，例如（order=聚合根，item=child of order）：
event_type=ITEM_OPEN
context_1_key=ORDER_ID
context_1_value=1000
context_2_key=ITEM_ID
context_2_value=2000
不，我不喜欢，不，我不应该为此负责。
问题：
- context_1_xxx 领域脆弱且难以maintain/troubleshoot/expand
- 将所有东西都塞进一个 table 将是一个性能问题（即使报告对性能不敏感）
- 事件链接到域object；它们不存储 object 的状态。例如。如果项目被删除，记录的事件是无用的
我的直觉告诉我，创建 40 个不同的 tables 并为每个事件设置唯一的模式并不是答案。相反，我正在考虑序列化（JSON）要与事件数据一起保存的域 object(s) 的快照。
看来方便解决：
- 我们已经使用 Spring/Jackson 模块为 browser-based 客户端序列化 object。
- 团队非常适应table serialize/deserialize 流程，因此没有主要的学习曲线。
- 事件数据必须通过应用程序返回以生成报告，de-serializing 和 Jackson 会很容易
我能看到的唯一真正的缺点是： - 无法使用基于 SQL 的第三方报告工具 - 无法在存储的 object(JSON)
的属性上索引 tables我可以通过将事件存储进一步分解为几个不同的 table 来稍微缓解问题 #2。
我还缺少什么？是否有既定的 best-approach 来实现这一点？你是怎么做到的？
从 Greg Young 的 Building an Event Storage 开始。
Konrad Garus 描述了一个使用 PostgresSQL 的事件存储。
My gut tells me creating 40 different tables with schema unique to each event is not the answer.
可能不会。对于所有类型的事件，第一次剪辑应该是单个 table。您有一个用于事件数据的 blob（json 很好），还有一个用于事件 metadata 的类似 blob，然后是一堆用于提取正确排序的列事件的历史。
Instead I was thinking of serializing(JSON) a snapshot of the domain object(s) to be saved along with the event data.
这是一个奇怪的短语。 JSON 事件数据的表示？这就说得通了。
不过，"Snapshot" 让人大跌眼镜——您不需要事件数据的快照，因为事件是 immutable。您肯定不希望将状态快照（即汇总事件历史的结果）与事件本身混合在一起。
跟进：查看 GetEventStore .NET 客户端 writes and reads 事件历史记录可能会给您关于如何设计架构的更多想法。请注意，事件 data/metadata 正在作为 blob 处理。