微服务的划分-订单消息发送规则位置

现在有一个问题 要推送一定规则(比如订单接单了多长时间，根据订单类型等采取不同推送策略)推送订单消息给客户。现在已经有了两个模块，一个是订单模块，一个是消息模块。订单消息的推送规则逻辑处理应该放在哪里？

现在有两个方案一个是订单状态变更时发送mq，消息模块接收消息，按照规则处理发送消息。一个是订单模块自己按照规则处理，把最终的处理结果发送mq。消息模块根据mq直接发送消息，不做规则判断。

这问题看似是消息发送逻辑的处理，其实这背后是微服务划分标准的问题。在微服务的实践中，人们常常出现标准的混乱。导致后面的工作变得艰难，出现困惑，怎么划分都觉得不合理，这其实没有按照统一的标准划分，服务存在重合造成的。

一般认为尽量根据业务边界来划分微服务。这里面我们首先明确服务边界，只有搞明白这个问题，才能可以思考上面的问题。订单模块毫无疑问是业务上划分，解决的问题是订单流程处理。消息模块它没有业务性，它是我们为了解决某一个业务问题而采取技术手段，所以它是一个技术域。所以问题也变得非常简单了，消息发送规则的处理是业务问题还是技术问题，显然是一个业务问题。所以消息发送规则处理放到订单模块。
如果说发送规则处理放到消息模块。那么他们的相关性就是他们都处理消息的。这种片面的划分方式无疑会给我们后面的工作带来更多疑惑。

消息规则放到订单模块里
优点

• 业务上：服务更内聚，逻辑的更集中
• 团队组织上：订单规则的处理也是订单维护的，如果放到偏技术层面的消息发送模块会出现不同业务团队都去修改消息模块或者业务团队让消息模块团队修改业务规则，带来更多的沟通成本。
• 技术层面：减少网络请求，减少系统间交互，减少系统调用。

缺点：

• 代码：更加臃肿
• 合作：削弱消息模块存在价值

消息规则放到消息模块里 上面优缺点几乎是反过来的。
选择适合团队和系统特点的方案，并在实际实践中进行调整和优化，是确保系统稳健性和团队协作效率的关键。
我们团队偏小，项目时间紧，不适合高度依赖沟通完成的工作。