我是EDA的新手,我已经阅读了很多关于福利的内容,并且可能有兴趣在我的下一个项目中应用它,但仍然没有理解.
在举办活动时,哪种模式最适合:
将事件命名为"CustomerUpdate",并包含有关客户的所有信息(已更新或未更新)
将事件命名为"CustomerUpdate",并仅包含实际已更新的信息
将事件命名为"CustomerUpdate"并包含最小信息(标识符)和/或URI,以便使用户检索有关此客户的信息.
我问这个问题是因为我们的一些活动可能很繁重而且频繁.
谢谢你的答案和时间.
将事件命名为"CustomerUpdate"
首先让我们从您的活动名称开始.事件的目的是描述已经发生的事情.这与命令不同,命令是针对尚未发生的事情发出指令.
您的事件名称"CustomerUpdate"在这方面听起来含糊不清,因为它可能描述过去或未来的某些内容.
CustomerUpdated会更好,但即便如此,Updated还是另一个含糊不清的术语,在业务环境中是非特定的.为什么客户在这种情况下更新了？是因为他们改变了付款细节吗？搬回家了？他们从白银升级到黄金状态？事件可以根据需要进行定制.
这似乎最初可能是过度思考,但事件命名变得特别相关,因为您从事件有效负载中删除数据和上下文,更多地转向瘦的事件(您的问题中的"选项3",我将在下面讨论).
这并不是说在这个粒度级别定义事件总是合适的,只是它是一个在项目早期对您开放的途径,可能会在以后支付股息(或者可能会让您陷入数千次事件中类型).
回到你的实际问题,让我们依次选择你的每个选项:
将事件命名为"CustomerUpdate",并包含有关客户的所有信息(已更新或未更新)
让我们把这个"模式"称为Fat消息.
胖消息(也称为快照)表示在给定时间点所描述的实体的状态,其中所有事件上下文存在于有效载荷中.它们很有趣,因为消息本身代表了服务和消费者之间的契约.它们可以用于在业务域之间传递状态的变化,其中可能优选的是在消费者的消息处理期间存在所有事件上下文.
好处:
自我一致 - 可以在不了解其他系统的情况下完全消费.
易于消费(upsert).
缺点:
脆弱 - 服务和消费者之间的契约与消息本身相关联.
如果消息以错误的顺序到达,则容易用旧数据覆盖当前数据(提示:您可以通过使用事件源模式来缓解这种情况)
大.
将事件命名为"CustomerUpdate",并仅包含实际已更新的信息
让我们称这种模式为Delta消息.
Deltas在很多方面与胖消息类似,但它们通常更难以生成和消费.这里的一个很好的例子是JSONPatch标准.
因为它们只是事件实体的部分描述,所以增量也带有内置的"假设",消费者知道所描述的事件.出于这个原因,它们可能不太适合在业务领域之外发送,其中事件实体可能不是众所周知的.
当在共享相同实体模型的系统之间同步数据时,Deltas真的很闪耀,理想情况是在非关系存储(例如,no-sql)中持久化.在这种情况下,可以检索实体,应用增量,然后以最小的努力再次持久化.
好处:
比Fat消息小
Excel介绍涉及共享实体模型的用例
缺点:
脆弱 - 类似于Fat消息,合同嵌入在消息中.
使用旧数据轻松覆盖当前数据.
复杂的生成和消费
将事件命名为"CustomerUpdate"并包含最小信息(标识符)和/或URI,以便使用户检索有关此客户的信息.
我们称之为Skinny消息.
瘦的消息与您定义的其他消息模式不同,因为消息中的服务/消费者合同不再明确,但暗示消费者稍后将检索事件上下文.这使合同和消息交换脱钩,这是一件好事.
这可能会也可能不适合事件的跨业务域通信,具体取决于您的企业的设置方式.因为事件有效负载非常小(通常只是一个ID),所以除了消费者可以根据处理决策做出的事件名称之外,没有任何上下文; 因此,确保事件被正确命名变得更加重要,特别是如果消费者有多种方式可以响应CustomerUpdated消息.
此外,在事件数据中包含实际资源地址可能不是一个好习惯 - 因为事件是已经发生的事情,事件消息通常是不可变的,因此事件中的任何信息都应该永远为真,以防事件需要重播.在这种情况下,资源地址很容易变得过时,事件将无法重新播放.
好处:
将服务合同与消息分离.
有关事件名称中包含的事件的信息.
自然幂等(带时间戳).
一般很小.
易于生成和使用.
缺点:
消费者必须进行额外调用以检索事件上下文 - 需要明确了解其他系统.
在消费者检索事件上下文时,事件上下文可能已经过时,使得这种方法通常不适合某些实时应用程序.
在举办活动时,哪种模式最适合？
我希望你现在已经意识到这个问题的答案取决于它.我会在这里停下来 - 你的问题是一个很好的问题,因为你可能会在回答它时写一本书,但我希望你发现这个答案很有帮助.
京公网安备 11010802040832号 | 京ICP备19059560号-6 