内容简介:在事件的生产者这边设计一组领域事件,这些事件能够可完整用于重建生产者的状态。通常,生产者发出的事件是随意设计的。只要新功能需要,就会添加新事件类型。消费者需要了解事件,因此我们在生产者这边提出对事件进行设计,给它起一个名字,并添加消费者需要的一些属性。
在事件的生产者这边设计一组领域事件,这些事件能够可完整用于重建生产者的状态。
问题
通常,生产者发出的事件是随意设计的。只要新功能需要,就会添加新事件类型。消费者需要了解事件,因此我们在生产者这边提出对事件进行设计,给它起一个名字,并添加消费者需要的一些属性。
然后可能稍后添加另一个消费者,并重用一些现有事件,但它只需要一些额外的信息,新属性将添加到现有事件中,当消费者被删除,这些事件仍然存在。
过了一段时间,很难理解曾经使用哪些事件,它们包含的内容以及它们的确切含义。消费者间接地相互耦合,生产者需要支持向后兼容越来越多的混乱事件。
解决
我们需要一个组织原则来回答“事件中发生了什么?”这一问题,从整体上设计生产者的一系列事件。
一个完整性保证的理念是,如果消费者监听整个领域事件流,它必须能够忠实再现生产者的整个状态 。
生产者中的每个操作都会更改状态,导致发出事件,并且每个事件都包含受状态更改影响的每个信息单元。最重要的是,理想情况下事件不包含冗余信息:事件只有已更改的属性,而不是单个属性。(注意: Fat Events 讨论了您想要添加冗余属性的情况。)
完整性保证的效果是,它会让事件变得清晰明显,哪些事件是相关的,它们是什么意思,它们包含什么属性等等。可以在生产者中实现的任何特征都可以在消费者中实现。 没有遗漏的信息。 这使系统设计人员能够选择移动实现某些职责功能的位置。
完整性保证给予消费者很大程度脱钩的:他们从来没有需要查询的生存者,因为他们已经有机会获得所有信息。
实现
在使用Event Sourcing的系统中,您可以免费获得完整性保证。我将Event Sourcing定义为持久性风格,其中领域事件存储是系统状态的唯一真实来源。状态可以以其他方式存储,但是该状态是可丢弃的,并且可以从事件存储库重建。如果事件是单一的事实来源,那么可以重建所有状态,因此保证是合理的。
对于习惯于事件采购/溯源的系统设计人员来说,自然保证完整性数据一致性。模式的要点是表明它在Event Sourcing之外也很有用。
当系统的单一事实来源是传统数据库(存储状态而不是事件)时,您如何实际实现这种保证?一种方法是为它编写测试。此测试侦听生产中的所有事件,并将它们投影到与生产者的实际模式相同的模式环境中。该测试将投影状态与生产状态进行比较,并在存在差异时发出警报。但是,您可能最好只使用事件采购溯源,而不需要为构建和运行这种类型的测试而付出努力。
以上所述就是小编给大家介绍的《分布式系统中的解耦模式:完整性保证 - mathiasverraes》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:- 解耦并不难:分布式系统中的解耦
- 分布式系统中解耦的模式:胖事件 - mathiasverraes
- 分布式系统中的解耦模式:领域查询 - mathiasverraes
- 分布式系统中的解耦模式:概要事件 - mathiasverraes
- 分布式系统中的解耦模式:隔离事件层 - mathiasverraes
- 分布式系统解耦模式:用事件代表时间触发Cron计划任务
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
The Facebook Effect
David Kirkpatrick / Simon & Schuster / 2010-6-8 / USD 26.00
《Facebook 效应》的作者近距离地采访了与Facebook相关的人士,其中包括Facebook的创始人、员工、投资人、意向投资人以及合作伙伴,加起来超过了130人。这是真切详实的访谈,更是超级精彩的故事。作者以其细腻的笔触,精巧的叙事结构,解密了Facebook如何从哈佛的宿舍里萌发,创始人的内讧,权力之争,如何放弃华盛顿邮报的投资,怎样争取到第一个广告客户,而第一轮融资又如何获得一亿美元的......一起来看看 《The Facebook Effect》 这本书的介绍吧!