如何在事件来源的储蓄账户申请中正确建立利息累积模型？

Question

在我使用DDD开发的事件源应用程序中，有一些储蓄帐户应该每天积累兴趣。在每年年底，累计利息应该资本化。我的问题是：每日计算是否真的被视为域事件？

另一种方法是通过遍历账户上发生的交易直到当天（提款，存款等）计算读取方的给定时间点的累计利息，并将每天的累计利息加起来。

事件存储中的事件数量将迅速增加到数百万，因为系统中可能有数十万个存储帐户每天计算其累积利息。但与此同时，在飞行中计算累积的兴趣似乎是一个缺点。在阅读方面而不是每天举办活动。

Answer 1

我不是银行专家，但InterestCredited看起来像你真正想要存储的事件，因为它会改变系统的状态。

累积兴趣是一个虚拟概念，如果我理解正确 - 将其建模为自己的事件不会增加任何价值。无论每天InterestAccumulated事件发生，您都可以计算年末的资本化利息。相反，每天重新计算的简单读取值似乎很好地符合需求。

Answer 2

利息累积只是在记入/记入帐户时的域事件。在此之前，它不会改变聚合状态。考虑纠正事件，发布错误（例如NSF信用逆转）。您需要更正原始和更正之间的每日错误利息计算。

阅读方可以在任何所需的时间间隔内处理累计利息。

Answer 3

  

每日计算是否真的应被视为域事件？

您的域名专家说了什么？

您可能还想查看the blue book的第11章，其中包括“示例：通过帐户获取利息”。这可能无法直接回答您关于域事件的问题，但它应该为您提供一些额外的背景来构建您自己的分析。

我不是域专家，但我的期望是，累积的利息会产生影响，无论是合法的还是模型的，并且您希望获得一致的应计记录以及对其产生的影响你的模特。

从最初的描述来看，对模型的影响是年度的，所以我希望每个帐户每年只能看一次InterestCapitalized事件。但我发现很难相信每日积累的利息无关紧要，尤其是面对不断变化的平衡和复利，所以我怀疑所描述的要求实际上符合企业的需求。

我不希望“数百万”事件成为一个大问题;使用CQRS模式，无论如何，你的大多数读取都将来自卷起的结果，所以这不是什么大问题。真正的伤害将是试图用数百万个事件重新补充聚合物;但如果您遇到性能问题，可以考虑从快照加载聚合。

当然，如果每个帐户都在计算自己的应计利息，那么你每年只会看365个额外的活动，这根本就没什么好事。