如何在事件源储蓄账户应用程序中正确模拟利息累积？
How to properly model interest accumulation in an event sourced savings account application?
在我使用 DDD 开发的事件源应用程序中，有一些储蓄账户应该每天累积利息。每年末将累计利息资本化。我的问题是：每天的计算真的应该被视为领域事件吗？
另一种方法是在读取端计算给定时间点的累计利息，方法是遍历截至当天在账户上发生的交易（提款） , 存款等), 然后将每天的累计利息相加。
假设系统中可能有数十万个储蓄账户每天计算他们的累积利息，事件存储中的事件数量将迅速增长到数百万。但与此同时，必须在读取端计算累积利息 "on the fly" 而不是每天引发事件似乎是一个缺点。
我不是银行业专家，但 InterestCredited 看起来像是您真正想要存储的事件，因为它会改变系统的状态。
如果我理解正确，累积利息 是一个虚拟概念 - 将其建模为事件本身不会增加任何价值。无论如何，无论是否存在每日 InterestAccumulated 事件，您都可以在年底计算资本化利息。相反，每天重新计算的简单读取端值似乎非常符合需求。
Should every daily calculation really be treated as a domain event?
您的领域专家怎么说？
您可能还想查看 the blue book 的第 11 章，其中包括 "Example: Earning Interest with Accounts"。这可能不会直接回答您关于域事件的问题，但它应该为您提供一些额外的上下文来构建您自己的分析。
我不是领域专家，但我的期望是应计利息会产生影响，无论是法律上的还是在模型中，并且您希望对应计利息和 它对你的模型的影响。
根据您最初的描述，对模型的影响是每年一次，因此我预计每个帐户每年只会看到一次 InterestCapitalized 事件。但我很难相信每日应计利息无关紧要，尤其是面对不断变化的余额和复利，所以我怀疑所描述的要求是否真的符合业务需求。
我不认为 "millions" 的事件会成为一个大问题；使用 CQRS 模式，无论如何，您的大部分读取都将来自汇总结果，所以这没什么大不了的。真正的伤害将在于尝试重新水合具有数百万个事件的集合；但如果您在那里遇到性能问题，您可以考虑从快照加载聚合。
当然，如果每个账户都在计算自己的应计利息，那么您每年只需要查看 365（大概）个额外事件，这一点也不费力。
利息积累只有在 credited/debited 进入帐户时才属于领域事件。在那之前，它不会改变聚合状态。考虑纠正事件，发布错误（例如 NSF 信用逆转）。您需要更正原始和更正之间的每个每日错误的利息计算。
读取方可以按所需的任何时间间隔累计累计利息。
在我使用 DDD 开发的事件源应用程序中，有一些储蓄账户应该每天累积利息。每年末将累计利息资本化。我的问题是：每天的计算真的应该被视为领域事件吗？
另一种方法是在读取端计算给定时间点的累计利息，方法是遍历截至当天在账户上发生的交易（提款） , 存款等), 然后将每天的累计利息相加。
假设系统中可能有数十万个储蓄账户每天计算他们的累积利息，事件存储中的事件数量将迅速增长到数百万。但与此同时，必须在读取端计算累积利息 "on the fly" 而不是每天引发事件似乎是一个缺点。
我不是银行业专家，但 InterestCredited 看起来像是您真正想要存储的事件，因为它会改变系统的状态。
累积利息 是一个虚拟概念 - 将其建模为事件本身不会增加任何价值。无论如何，无论是否存在每日 InterestAccumulated 事件，您都可以在年底计算资本化利息。相反，每天重新计算的简单读取端值似乎非常符合需求。
Should every daily calculation really be treated as a domain event?
您的领域专家怎么说？
您可能还想查看 the blue book 的第 11 章，其中包括 "Example: Earning Interest with Accounts"。这可能不会直接回答您关于域事件的问题，但它应该为您提供一些额外的上下文来构建您自己的分析。
我不是领域专家，但我的期望是应计利息会产生影响，无论是法律上的还是在模型中，并且您希望对应计利息和 它对你的模型的影响。
根据您最初的描述，对模型的影响是每年一次，因此我预计每个帐户每年只会看到一次 InterestCapitalized 事件。但我很难相信每日应计利息无关紧要，尤其是面对不断变化的余额和复利，所以我怀疑所描述的要求是否真的符合业务需求。
我不认为 "millions" 的事件会成为一个大问题；使用 CQRS 模式，无论如何，您的大部分读取都将来自汇总结果，所以这没什么大不了的。真正的伤害将在于尝试重新水合具有数百万个事件的集合；但如果您在那里遇到性能问题，您可以考虑从快照加载聚合。
当然，如果每个账户都在计算自己的应计利息，那么您每年只需要查看 365（大概）个额外事件，这一点也不费力。
利息积累只有在 credited/debited 进入帐户时才属于领域事件。在那之前，它不会改变聚合状态。考虑纠正事件，发布错误（例如 NSF 信用逆转）。您需要更正原始和更正之间的每个每日错误的利息计算。
读取方可以按所需的任何时间间隔累计累计利息。