Golang领域模型-领域事件

DDD

freedom

领域事件是领域驱动设计中的一个重要概念，我们使用领域事件来捕获领域中发生的一些事情。只有那些对业务有价值，能够有助于形成完整的业务闭环，能够推动下一步业务发展的事情，才能被当做领域事件。

这里举一个例子，当用户在订单服务下单付款后，仓储物流团队就可以开始进行发货流程发货了。当用户确认收货后，发票服务的会计团队就能开始做账报税开票了。这一系列的动作都是属于事件，属于各自领域的事件，并且明显的能够推动业务的发展！

随着微服务的兴起，拆分服务和事件风暴在不断的演进，领域事件扮演着灵魂角色。在事件风暴中，发现并提取领域事件，将以领域事件为中心的业务模型，演化成以聚合为中心的领域模型，是DDD落地实践的一种重要手段。

领域事件是属于领域模型的，前面我们已经介绍过聚合和实体都是领域模型。在领域事件建模时，我们因该关注这一点。用户实体修改密码？订单聚合支付？订单聚合发货？它们完成命令后是否因该发布通知？

在数据的最终一致性的问题上，我们至少要保证该限界上下文内领域模型的持久化和领域事件的发布是一致的。

如果订单状态修改为已付款，然后在使用MQ基础设施发布失败，那么是不一致的。那么如果是先使用MQ基础设施发布成功，然后在修改订单状态为已付款失败，也是不一致的。

我们需要一张事件表和使用本地事务。在领域模型持久化的同时并插入一条领域事件的记录，它们依赖本地事务来保持数据的一致性。

当事务成功后再使用MQ基础设施发布通知，如果失败了，定时器扫描后继续发送直至发送成功。

看到这里你可能觉得会很麻烦和复杂，其实只要代码设计的漂亮，这不过是几行代码的事情。

freedomMQHTTP APIRPCGolangChannelCond

Topic

IDUUID

虽然事务成功立刻发布消息，定时器只是重试失败的发布，但依然会存在发布和消费的延迟。我们因该细心的评估这种影响。是否可以接受？如果不能接受并且要加入中间状态（例如‘订单确认中’），是否产生依赖和耦合？

Query

领域事件也会有陷阱，最常见的是被动操控型命令。《一、什么是领域事件》已经简单介绍过命令和事件。

这里还是举个例子，当用户为订单付款后，订单发布事件的Topic如果是订单已支付，这是属于该订单领域模型自身发布的领域事件，这个是正确的。如果Topic是开发票，订单这个领域模型让谁开发票？？？这是错误的，这就是被动操控型命令(Passive-aggressive command).

创建一个修改密码的领域事件

在实体修改密码的行为中使用领域事件

领域服务的处理

资源库的处理

领域事件组件介绍

目录