在事件/消息驱动的体系结构中建模事件或消息

Question

我正在对在微服务集成中使用的消息进行建模。你见过特定于消息的设计模式吗？

例如，在下面的消息中，如果ID为F123的子项被删除，我该如何表示？

这里有一个小陷阱，因为我可以从实体子节点发送删除事件，但在这种情况下，我只想终止实体父节点x实体子节点之间的关系。因此，我的事件是实体父中的更新，以删除与实体儿子的关系。

消费者可以在消息和本地数据之间做一个比较，但是比较每个具有大量数据的消息可能是非常昂贵的。

{
   "header":{
      "op":"updated_father"
   },
   "body":{
      "id":"1234",
      "entity_type":"father",
      "childs":[
         {
            "child":{
               "id":"f123",
               "entity_type":"son"
            }
         },
         {
            "child":{
               "id":"f333",
               "entity_type":"son"
            }
         }
      ]
   }
}

谢谢大家！

Answer 1

事件消息最棒的一点是:您不会被强制使用CRUD动词。

因此，可以根据需要对事件进行精确建模，并且事件名称应该具有业务意义。我们所说的商业意义是什么？

如果一个事件描述了在真实的业务环境中发生的事情，那么它就具有业务意义。具有业务意义的事件名称示例：

• 发票已提高
• 股票

升级版

当业务人员能够理解您的事件名称的含义时，您的事件就具有了业务意义。另一方面，如果业务人员对您的事件名称感到困惑，您知道您的事件只具有技术意义。

为什么更新此记录？是哪一个？

写这个答案的目的是试图给你一种新的方式来思考事件，这将有望将你从CRUD的限制中解放出来。