分布式系统中的解耦模式:完整性保证 - mathiasverraes

19-05-13 banq
                   

在事件的生产者这边设计一组领域事件,这些事件能够可完整用于重建生产者的状态。

问题

通常,生产者发出的事件是随意设计的。只要新功能需要,就会添加新事件类型。消费者需要了解事件,因此我们在生产者这边提出对事件进行设计,给它起一个名字,并添加消费者需要的一些属性。

然后可能稍后添加另一个消费者,并重用一些现有事件,但它只需要一些额外的信息,新属性将添加到现有事件中,当消费者被删除,这些事件仍然存在。

过了一段时间,很难理解曾经使用哪些事件,它们包含的内容以及它们的确切含义。消费者间接地相互耦合,生产者需要支持向后兼容越来越多的混乱事件。

解决

我们需要一个组织原则来回答“事件中发生了什么?”这一问题,从整体上设计生产者的一系列事件。

一个完整性保证的理念是,如果消费者监听整个领域事件流,它必须能够忠实再现生产者的整个状态

生产者中的每个操作都会更改状态,导致发出事件,并且每个事件都包含受状态更改影响的每个信息单元。最重要的是,理想情况下事件不包含冗余信息:事件只有已更改的属性,而不是单个属性。(注意:Fat Events讨论了您想要添加冗余属性的情况。)

完整性保证的效果是,它会让事件变得清晰明显,哪些事件是相关的,它们是什么意思,它们包含什么属性等等。可以在生产者中实现的任何特征都可以在消费者中实现。 没有遗漏的信息。这使系统设计人员能够选择移动实现某些职责功能的位置。

完整性保证给予消费者很大程度脱钩的:他们从来没有需要查询的生存者,因为他们已经有机会获得所有信息。

实现

在使用Event Sourcing的系统中,您可以免费获得完整性保证。我将Event Sourcing定义为持久性风格,其中领域事件存储是系统状态的唯一真实来源。状态可以以其他方式存储,但是该状态是可丢弃的,并且可以从事件存储库重建。如果事件是单一的事实来源,那么可以重建所有状态,因此保证是合理的。

对于习惯于事件采购/溯源的系统设计人员来说,自然保证完整性数据一致性。模式的要点是表明它在Event Sourcing之外也很有用。

当系统的单一事实来源是传统数据库(存储状态而不是事件)时,您如何实际实现这种保证?一种方法是为它编写测试。此测试侦听生产中的所有事件,并将它们投影到与生产者的实际模式相同的模式环境中。该测试将投影状态与生产状态进行比较,并在存在差异时发出警报。但是,您可能最好只使用事件采购溯源,而不需要为构建和运行这种类型的测试而付出努力。