我有一个事件源系统,它有3个微服务(简化):
我有一个要求,我们想让Demo用户可以像其他用户一样使用应用程序,但我们不想向他们发送任何通知。
当然,这是一个例子,但是您可以看到其他服务也可以基于这个事实(演示与否)有不同的行为。
我想问你什么是最好的选择来实现这一点。当然,我可能弄错了微型服务部分。
demo标志,因此它如下所示:UserRegistered(email, demo)Notifications服务中侦听此事件,然后决定将没有demo标志的用户添加到它的内部存储中Notifications服务侦听AccountBalanceDebited(user, debit)事件时,它只会忽略用户在内部存储中没有的事件。缺点是我可能最终会向UserRegistered事件添加更多的东西
UserRegistered或DemoUserRegistered事件UserRegistered服务中监听Notifications事件Notifications服务接收到AccountBalanceDebited事件时,我检查是否有用户记录(与潜在的实现1相同)缺点是,对于用户和演示用户,我们有很多常见的行为,所以在大多数情况下,我们需要侦听这两个事件。
UserRegistered(email)事件,如果这是演示用户,则创建UserDemoModeActivated(user_id)Notifications服务中,我监听这两个事件,在UserDemoModeActivated上,我只是从内部存储中删除用户记录,并按照以前的实现进行处理。我不想使用
实现
在Notifications服务中,获取用户实体(基本上是共享模型),并在这里检查演示标志。
我越多地想到它,我就越深入到第三个解决方案中,我喜欢的是它更多地是一个补充而不是系统中的一个变化。
这是我第一次接触ES,所以我很乐意得到帮助。
发布于 2019-04-08 21:25:15
当用户注册时,我假设他们特别选择接受通知,因为法律规定,如欧盟的GDPR条例。因此,在用户帐户注册期间可以有两个事件:UserRegistered和UserOptedInToReceiveNotifications。
选择进入事件将被通知服务使用,以配置他们的帐户以接收电子邮件。对于演示用户,您不会创建第二个选择事件,因此这些用户将不会收到电子邮件。这确保通知服务只处理特定选择接收您通知的用户。
这种方法的另一个好处是,演示用户以后可以通过现有的UserOptedInToReceiveNotifications事件选择加入通知,这样就可以像以前一样启动通知服务。
发布于 2019-04-08 15:53:44
复制通知服务上的所有用户肯定是个错误。
我通常采取的方法被概括为“脂肪事件”。而不是发送:
UserRegistered
Email
BalanceUpdated
UserId
NewBalance我会发送:
UserRegistered
User : { id, email, address, category (demo)....}
BalanceUpdated
User : { id, email, address, category (demo)....}
BalanceChange : {id, date, amount, currency... }这样,侦听事件的服务可以采取各种各样的操作,而不必查询其他服务或保存它们自己的数据版本。
您的通知服务可以简单地检查消息中包含的用户对象的属性,并应用其逻辑来确定是否应该向该用户发送消息。
另一种选择。通知设置,如“不接收营销邮件”等,显然是通知服务的一部分。您可以让演示用户在通知服务上设置他们的设置,以便不接收通知。
发布于 2019-04-08 17:31:01
对于微服务间通知,我会采取完全相反的方式--根本没有有效负载,只是类型、事件发生和id。
Registered { "User", userId }这样,任何侦听服务都可以做出“我关心这个事件吗”的决定,如果是这样的话,可以向源服务询问最新的状态。这样,如果两个通信服务中的任何一个处于脱机状态,它们就可以轻松地重新同步。
但是,就演示或测试用户而言,您确实希望系统中的大部分内容完全相同,并且只需要以不同的方式进行不同的编码。
在我看来,这意味着在通知服务中有一个“不要发送”电子邮件列表,并为演示用户提供那些电子邮件地址。
https://softwareengineering.stackexchange.com/questions/389992
复制相似问题