在事件的生产者这边设计一组领域事件，这些事件能够可完整用于重建生产者的状态。
问题
通常，生产者发出的事件是随意设计的。只要新功能需要，就会添加新事件类型。消费者需要了解事件，因此我们在生产者这边提出对事件进行设计，给它起一个名字，并添加消费者需要的一些属性。
然后可能稍后添加另一个消费者，并重用一些现有事件，但它只需要一些额外的信息，新属性将添加到现有事件中，当消费者被删除，这些事件仍然存在。
过了一段时间，很难理解曾经使用哪些事件，它们包含的内容以及它们的确切含义。消费者间接地相互耦合，生产者需要支持向后兼容越来越多的混乱事件。
解决
我们需要一个组织原则来回答“事件中发生了什么？”这一问题，从整体上设计生产者的一系列事件。
一个完整性保证的理念是，如果消费者监听整个领域事件流，它必须能够忠实再现生产者的整个状态。
生产者中的每个操作都会更改状态，导致发出事件，并且每个事件都包含受状态更改影响的每个信息单元。最重要的是，理想情况下事件不包含冗余信息：事件只有已更改的属性，而不是单个属性。（注意：Fat Events讨论了您想要添加冗余属性的情况。）
完整性保证的效果是，它会让事件变得清晰明显，哪些事件是相关的，它们是什么意思，它们包含什么属性等等。可以在生产者中实现的任何特征都可以在消费者中实现。 没有遗漏的信息。这使系统设计人员能够选择移动实现某些职责功能的位置。
完整性保证给予消费者很大程度脱钩的：他们从来没有需要查询的生存者，因为他们已经有机会获得所有信息。
实现
在使用Event Sourcing的系统中，您可以免费获得完整性保证。我将Event Sourcing定义为持久性风格，其中领域事件存储是系统状态的唯一真实来源。状态可以以其他方式存储，但是该状态是可丢弃的，并且可以从事件存储库重建。如果事件是单一的事实来源，那么可以重建所有状态，因此保证是合理的。
对于习惯于事件采购/溯源的系统设计人员来说，自然保证完整性数据一致性。模式的要点是表明它在Event Sourcing之外也很有用。
当系统的单一事实来源是传统数据库（存储状态而不是事件）时，您如何实际实现这种保证？一种方法是为它编写测试。此测试侦听生产中的所有事件，并将它们投影到与生产者的实际模式相同的模式环境中。该测试将投影状态与生产状态进行比较，并在存在差异时发出警报。但是，您可能最好只使用事件采购溯源，而不需要为构建和运行这种类型的测试而付出努力。