在领域驱动设计聚合中管理无界集合的最佳实践

Question

我正在使用领域驱动设计（DDD）设计电子钱包系统，并且我面临着有关聚合设计的挑战。具体来说，我有一个代表电子钱包的聚合，其中包含交易集合。随着时间的推移，交易列表可能会无限增长，而且我不确定在聚合中处理这个无界集合的最佳方法。

这是我当前聚合结构的简化示例：

public class Wallet {
    private String walletId;
    private List<Transaction> transactions;
}

public class Transaction {
    private String transactionId;
    private UsdAmount amount;
}

考虑到交易列表可能会变得相当大，我担心潜在的性能和可扩展性问题。我也不确定如何在处理这个无界集合时保持聚合的完整性。

注意：我不能将事务视为独立的聚合，因为它们缺乏重要的业务逻辑或行为。

在尝试解决这一挑战时，我尝试了创建专门用于管理事务实体上的只读操作的域服务的想法。该域服务将封装诸如查询、过滤和检索与钱包相关的交易等操作。通过将此域服务传递给任何需要使用交易列表的聚合行为，我的目的是模拟延迟加载并最大限度地减少钱包聚合本身的复杂性。

虽然使用“域服务”进行只读事务操作的方法似乎很有前途，但我不确定它的长期影响以及它是否符合 DDD 的最佳实践。我特别担心潜在的缺点，例如域服务和钱包聚合之间的耦合增加。 我正在寻求社区的反馈和见解，了解这种方法是否被认为是 DDD 中的良好实践，以及是否有其他策略可以更有效地管理聚合中的无界集合。任何指导或建议将不胜感激。

Answer 1

考虑到交易列表可能会变得相当大，我担心潜在的性能和可扩展性问题。我也不确定如何在处理这个无界集合时保持聚合的完整性。

首先提醒：

潜在的

性能和可扩展性问题不是实际的性能和可扩展性问题。 “仅仅”通过简单的设计推出 MVP 并推迟问题直到有足够的流量来激励工作是有意义的（参见Jeff Dean，2009）。 我在事件溯源系统中经常看到的机械解决方案是

快照

。实际上，您将需要记住的信息“投影”到文档/报告/快照中，并使用描述流中生成报告的点的元数据，然后处理加载该文档以及任何后续消息的新消息事件。 如果您稍微想一下，这就是您已经在做的事情，从某种意义上说，在处理所有事件时，在任何事件出现之前，都会有一个聚合外观的隐式快照。我们只是采用这个概念，并 (a) 使其明确，(b) 使其可持久化，以及 (c) 引入从流开头以外的某个点开始的选项。

（注意：这些快照是异步生成的似乎很常见 - 我们在锁定和更新事件流时不需要锁定和更新快照。）

我经常看到的领域解决方案在聚合的定义中明确了时间；我们不是永远跟踪历史上的每一个事件，而是按财务季度（例如）将它们分解，并制定流程将信息从一个财务季度滚动到下一个财务季度。

换句话说，您可以将无界域进程替换为一系列时间盒域进程。