我正在为微服务集成中使用的消息建模。你见过专门针对消息的设计模式吗？
例如，在下面的消息中，我如何表示ID为F123的孩子是否被删除？
有一个小陷阱，因为我可以从实体Son发送删除事件，但在这种情况下，我只想终止实体Father x实体Son之间的关系。所以，我的事件是在实体父亲中更新，删除与实体儿子的关系。
消费者可以在消息和本地数据之间进行区分，但将每条消息与高数据量进行比较可能会非常昂贵。
{
"header":{
"op":"updated_father"
},
"body":{
"id":"1234",
"entity_type":"father",
"childs":[
{
"child":{
"id":"f123",
"entity_type":"son"
}
},
{
"child":{
"id":"f333",
"entity_type":"son"
}
}
]
}
}
谢谢大家！
事件消息的一大优点是：您不必拘泥于CRUD动词。
事件消息是对过去发生的有趣事情的描述。因此，可以根据需要对事件进行精细建模，并且事件名称应该具有商业意义。我们所说的商业含义是什么意思？
如果一个事件描述了在真实的商业环境中发生的事情，那么它就具有商业意义。具有商业意义的事件名称示例：
- 开具的发票
- 库存耗尽
- 签订的合同
- 客户已升级
如果业务人员能够理解您的活动名称的含义，那么您的活动就具有业务意义。另一方面，如果公司的人会被你的活动名称弄糊涂，你就知道你的活动只有技术意义。
因此，您当前的事件名称updated_father实际上没有任何商业意义。为什么要更新此记录？更新此记录可能有10个不同的业务原因。是哪一个？
同样，基于导致事件生成的实际业务原因，对两个记录(在您的示例中为父子记录(之间的技术关系的更改只是一种新类型的事件。
写这个答案的目的是试图给你一种思考事件的新方式，这将有望让你摆脱CRUD的限制。