假设我的系统中有一个将设置用户电子邮件的操作，如果我从 CQRS 和事件溯源的角度多次设置相同的电子邮件会发生什么情况？
只有一次：
客户联系人信息设置事件
或者，继续附加：
客户联系人信息设置事件
客户联系人信息设置事件
客户联系人信息设置事件
客户联系人信息设置事件
该操作发出SetCustomerContactInformation命令。
在大多数情况下，如果新信息已匹配，则不会记录新的CustomerContactInformationSetEvent事件。
如果上述安排丢失了您网域中的重要信息，请根据需要进行调整。我假设事件溯源设置，其中事件顺序是已知的。
假设我的系统中有一个将设置用户电子邮件的操作，如果我从 CQRS 和事件溯源的角度多次设置相同的电子邮件会发生什么情况？
在大多数情况下，您希望域模型是幂等接收器;同一消息的多个副本应该没有可观察到的效果。
就您将在事件历史记录中看到的内容而言，您可能会看到以下任何方法：
日志中的单个事件，表示将邮件设置为新值时的点，并且首次出现邮件重复项时没有其他条目。 毕竟，模型没有改变，所以我们不需要在历史中创建变化的表示。
日志中的多个事件：捕获冗余事件在概念上没有任何问题 - 模型的下一个版本实际上可能不会将这些事件视为冗余事件，因此显式捕获它们可能会在以后产生额外的业务价值。
多个日志：一个记录所有传入消息的日志(即，预写日志(，以及一个单独的日志，其中包含描述状态更改的单个事件。
第一种方法可能是最常见的。 当事件可能无序到达时，记录许多事件可能很重要。
ChangeEmail: bob@example.org
ChangeEmail: alice@example.org
ChangeEmail: bob@example.org
要知道正确的电子邮件地址，您可能需要知道这些更改的顺序，这不一定是它们到达的顺序。
比较
ChangeEmail: bob@example.org time:1200
ChangeEmail: alice@example.org time:1300
ChangeEmail: bob@example.org time:1200
跟
ChangeEmail: bob@example.org time:1200
ChangeEmail: alice@example.org time:1300
ChangeEmail: bob@example.org time:1400
和
ChangeEmail: bob@example.org time:1200
ChangeEmail: bob@example.org time:1400
ChangeEmail: alice@example.org time:1300