微服务拆分的边界你怎么把握？

我的判断标准是按业务能力而不是技术层拆：订单、库存、支付各自是一个服务，而不是把所有 Controller 一层、所有 Service 一层。边界上要求数据自治——每个服务有自己的库，别人只能走接口拿数据。拆分粒度要克制，团队能驾驭多少服务就拆多少。

我经历过一次拆分实践：从单体里拆订单域。我们的做法是先按领域模型画边界——哪些表只能订单域访问、哪些事件要对外发布；用绞杀者模式逐步迁移，接口先聚合后下沉。教训是拆得太碎：初期拆了九个服务，跨服务联调成本爆炸，后来合并回四个。边界对不对，看变更是否经常跨服务就够了。

拆分边界我讲三个信号：组织信号——康威定律，服务边界对齐团队边界；变化信号——高频变更的逻辑聚在一起，稳定与易变的分开；数据信号——强一致的数据放一起，跨服务的只是事件同步。要主动讲反模式：分布式单体——服务拆了但还共享库同步调用链式依赖，比单体更糟。拆分是手段，独立演进才是目的。

追问『跨服务查询怎么办』：CQRS 思路，各自维护查询视图或用聚合网关组装，避免服务间直连库；『分布式事务』：优先业务上避免——最终一致加补偿，Seata 类框架按场景慎用；『怎么判断拆过头』：一次需求平均跨三个以上服务协作、全链路联调时间超过开发时间，就是信号。