【发布时间】：2014-08-19 18:23:41
【问题描述】：
为了评估目的，我正在尝试设置一个事件溯源应用程序，它是一个“个人财务软件”，第一次尝试是创建一个聚合根（帐户），您可以添加实体（交易/秒） .
帐户在软件生命周期中会收到大量事务，因此每次我需要添加事务时都必须越来越大地重新水合聚合。
所以我担心的是：
- 在这种情况下，事件溯源不是好的选择
- 应以不同方式映射实体。
【问题讨论】：
标签： event-sourcing
【发布时间】：2014-08-19 18:23:41
【问题描述】：
这显然是选项 2)。
我认为您不需要将每笔交易添加到帐户中——这里的一致性优势在哪里？
实际上，在底层业务领域，这正是他们（财务人员）首先引入交易的原因——交易是原子金融交易的一致概念，账户余额通常会更新为交易发生后几个小时或几天（参见起息日与交易日期）。
金融领域是一个完美的例子，其中诸如“事件溯源”和最终一致性之类的链接在实际领域中也很常见，它们非常适合长期运行的流程（传奇），并在其聚合上具有最终一致性。
【讨论】：
-
所以如果我理解的很好，我没有使用 DDD 样式（伪代码）Account.addTransaction(tx)。相反，我应该使用（伪代码）new Transaction（accountId，quantity...）.save（）。在这种情况下，如何以及在哪里检查 accountId 是否存在？
-
您可以使用
Account.credit(tx)或类似名称。new Transaction(...).save()不是 DDD 风格，使用存储库。如何确保帐户存在可能是您可以询问您的领域专家的问题。