如何在 DDD 中拆分大型时间相关聚合？

Question

我遇到了以下设计问题，但我一直无法找到满意的解决方案。欢迎任何指导。

考虑车辆路线的概念，其中路线是出发或到达已知地点的序列。对于给定的车辆，不能同时发生两个事件，并且出发必须在到达同一地点之后进行。这里的一个挑战是数据量，因为给定车辆可能存在数千个事件。

我们有两个主要用例：

• 批量更新，用新的事件序列替换路线的片段
• 分析事件序列（对于给定车辆）以检测各种模式。

到目前为止我所尝试/想到的：

• 对给定车辆使用单个“路线”聚合。这很简单，并且可以确保事件序列的一致性，但不幸的是无法扩展。
• 使用“RouteFragment”聚合来表示两个给定时间戳之间的车辆路线。这部分解决了可扩展性问题（希望两个时间戳不会相差太远），但我不确定如何确保片段之间的一致性。
• 使用“中途停留”聚合，这表示到达后又从同一已知地点出发。问题就变成了确保没有两个中途停留地重叠。
• 放弃聚合的想法，并使用某种可以定期处理和清理事件序列的服务。修复逻辑对我来说也不是很明显。

DDD 中是否有模式或策略来管理大量顺序事件，同时保持域不变量？我不太明白有关聚合的指导如何应用（聚合遵守事务边界，一笔事务应该只触及一个聚合，等等）

你会如何处理这个问题？

Answer 1

看来有两件事你可以申请。

第一个“GRASP控制器”：

问题：谁应该负责处理输入系统事件？ 解决方案：一个用例控制器应该用于处理一个用例的所有系统事件，并且可以用于多个用例。

在这种情况下，这可能意味着我们应该在域外、应用程序外层的边界处理与时间相关的事情。它将简化任务 - 您将考虑将事件保存到数据库并从数据库获取事件或事件列表的逻辑，而不是管理多个事件。此外，您可以简单地使用数据库中的事务来避免重复，而不是重复数据删除工作。

下一个 - 是“过早的优化是万恶之源。”

内存和CPU时间很便宜，而开发时间很昂贵。根据 K.Wiegers 的说法，提高性能总是会降低可修改性，反之亦然。但是，如果您的代码很容易修改，您可以随时更改它以获得更好的性能。

因此，您可以从最简单的事情开始：一条“路线”。如果您发现它的性能不适合系统，那么您可以对其进行修改并提高其性能。