微服务职责边界划分：NotificationService与OrderService权责如何界定？

针对你的具体疑问解答 #

你的个人判断完全正确，NotificationService的定位就该是纯通用的消息发送组件，不需要耦合任何业务相关逻辑：

• 完全不需要感知用户、订单类业务信息，你不需要向它传递用户实体、用户ID、消息类型这类业务属性，仅需要传递两类参数：已经渲染完成的完整消息内容、目标触达地址（手机号/邮箱/站内信账号等），可选补充发送渠道标识即可。
• 不需要主动请求业务数据库，它仅需要存储自身运维相关的数据，比如发送日志、各渠道的调用配置、限流规则等，绝对不应该直接访问用户、订单等属于其他业务域的数据库。

微服务边界与职责的判断标准 #

你可以用以下几个简单的规则快速校验边界是否合理：

• 单一职责校验：每个服务仅负责一类独立能力或一个完整的业务域。比如OrderService属于订单业务域，管所有订单生命周期内的逻辑，天然掌握订单关联的用户信息、通知内容规则；NotificationService属于通用能力层，仅负责「将指定内容发送到指定地址」这一件事，不需要关心内容来源、发送原因。
• 耦合度校验：如果某一个业务规则调整，需要同时修改两个及以上服务的代码，说明边界划分错误。比如你要调整订单成功的通知文案，只需要修改OrderService内的模板渲染逻辑，不需要改动NotificationService的任何代码，这种状态才是合理的。
• 数据归属校验：谁产生的数据谁全权负责维护，其他服务要使用该数据只能通过公开接口调用获取，禁止跨服务直接访问数据库。用户数据归用户服务、订单数据归订单服务，NotificationService不归属任何业务数据，仅消费其他服务传入的直接可用参数。
• 依赖反向校验：如果一个服务需要依赖N个其他服务的接口或数据库才能完成核心工作，说明它承担了不属于自身的职责。比如你如果让NotificationService拿着用户ID去调用用户服务查询手机号，就会导致通知服务强依赖用户服务，后续用户服务接口调整，通知服务也需要同步修改，完全没有必要。

内容的提问来源于stack exchange，提问作者user14514318