我正在尝试使用DDD对实时协作应用程序进行建模。某些热点事件的一个特殊功能是CAD可视化。
问题#1
多个参与者加入一个3D虚拟环境，其中一人被指定为促进者。尽管所有参与者都可以更改自己的各种偏好，但主持人可以更改所有用户的偏好。用户可以在个人级别上重新更改它们。
我面临的问题是，单个与批量操作。我是提交批量操作的细粒度事件还是提交单个事件？如果现有进程侦听细粒度事件，那么它将错过批量事件，除非显式地进行通信，否则不会产生如此干净的边界。
问题#2
有趣的是，这是问题#1的变体，但有点严重。CAD模型带有一些元结构，即DAG。每个叶级别结构都是一组一起操作的三角形。这些三角形组称为体积。一组卷形成了另一个概念，称为分支。一个分支可以包含其他分支作为子分支。分支+体积结构总是形成一棵树。一些不相交的树枝形成了另一个概念，称为群。
现在，参与者可以使分支/组/卷可见和隐藏。我是发布单个分支级事件，还是为正向路径中的每个分支/卷创建一个事件？
我曾考虑在同一主题下发布批量操作的批量事件和单个操作的单个事件。这感觉不太好，因为我可能会引入新的批量事件，并需要另一个下游上下文来打破。
或者，我考虑使用correlation_id发布批量和细粒度事件。如果理解了批量事件，下游可以忽略具有相同关联id的以下事件。尽管这看起来很有希望，但感觉仍然不好，因为下游可能同时处理事件，并且稍后的事件可能比批量事件更早处理。
能否使用DDD对批量操作进行适当建模？有没有办法重新思考更适合DDD的复合模式？
1.(bulk事件，id可以是对当时所有匹配id的查询，也可以是显式匹配id列表。你需要它，因为如果你想以某种方式恢复事件，那么如果你失去了单个事件之间的连接，你就会遇到问题。这是一个必须存储的infot。
2.(看起来像某种奇怪的图，它让我想起了科学的知识图：数学、物理、化学、生物学等。在数学的基础上，一切都是相互关联的，但人们仍然想把它们强行划分成一个层次。两门科学之间有一半的术语，所以当你选择一门科学的术语时，你无法决定它们属于哪一门。同样的解决方案是，用查询选择事物也适用于此。这个问题我也想了很多。在达到一定大小后，单个事件的负载将需要巨大的存储空间。最好将bulk与查询一起使用并计算它们，或者将id列表保存为查询缓存，但不要重复任何其他内容。至于半层次结构，我不知道如何正确地建模。我会使用一个简单的图，标记所有内容，并基于标记进行查询，但仍然有一种层次结构，如果没有任何加权，从纯图的角度很难理解。