我是事件溯源的新手，我遇到了一个我不太确定不同方法的优缺点的示例。
假设这是一个银行示例，我有三个实体 Account、Deposit 和 Transfer。
我的想法是，当用户存款时，命令bank.deposit 将创建两个事件：
deposit.created 和 account.deposited。我可以或应该在account.deposited 中包含deposit.created 事件uuid 作为参考吗？
进行下一步，如果以后银行有转账功能，我应该创建一个单独的事件account.transfer_received，还是创建一个更通用的事件account.credited，供存款和转账使用？
提前致谢。
【问题讨论】：
标签： event-sourcing
要评论的好文章是Nobody Needs Reliable Messaging。一项重要的观察是，您通常需要域级别的标识符。
例如，当我查看我的银行帐户，并看到帐户历史记录包含特定存款时，视图中报告了一个标识符存款。
如果您从事件来源的角度想象，在存款之前余额为 X，并且历史不包括存款 12345；处理完存款后，余额为 X+Y 并且存款 12345 在帐户历史记录中。
（这意味着，除其他外，如果要出现 second 个 deposit 12345 的副本，即使 event 的标识符，域模型也会知道忽略它em> 不同）。
现在，您可能出于某些原因想要保留各种消息 ID。参见 Hohpe 关于企业集成模式的工作；特别是Correlation Identifier。
我应该单独做一个活动吗
通常。 “使隐含的，明确的”。两个事件碰巧具有相似的表示这一事实并不是在通用语言区分这两者时模糊它们的理由。
在动机上，这有点类似于提供task based ui 或避开generic repositories 的用户。
【讨论】：