标准答案
- 先找业务能力和数据所有权，例如订单、库存、支付、通知各自的规则、状态和变化节奏，再判断是否需要独立服务。
- 技术层不应成为服务边界。把“用户 Controller”与“用户 DAO”拆成两个服务会制造高频远程调用，却没有带来业务自治。
- 团队负责边界需要与服务边界尽量一致，负责一个服务的团队应能负责它的代码、数据、发布、监控和故障处理。
- 需求还频繁变化、模块仍需要同一事务、同一团队一次发布就能解决问题时，通常说明先保留模块化单体更合适。
题目解析
服务边界的关键问题是“谁拥有规则和数据”。如果两个模块每次改动都要同步改表、同步发版、同步处理事务，它们往往尚未形成独立边界。
拆分后出现跨服务 Join、共享表写入、循环调用和频繁分布式事务，通常是过早拆分的信号，应优先回看业务模型而不是继续加中间件补洞。
常见误区
- 按数据库表数量一表一服务，导致大量细碎调用和跨服务聚合。
- 只按组织结构硬切，忽略业务规则和数据的实际归属。
- 把共享数据库当成长期方案，导致服务表面独立、实际无法独立演进。