服务边界识别方法

用途：确定某个能力应该落在哪个服务时查阅

三类输入

服务边界决策要同时看三件事，任一单独使用都会出错：

视角	问什么	工具
业务语义	这块能力的规则由谁定义、术语是否一致	限界上下文、统一语言、事件风暴
变更耦合	哪些代码总是一起改	版本历史的共变分析
组织结构	哪个团队负责、发布节奏是否冲突	康威定律、团队拓扑

语义视角

以限界上下文为主：一个上下文内的模型自洽，跨上下文必须翻译。若两个能力共享同一组不变式，就不要拆开；若同一个词在两边含义不同，就是天然边界。

变更耦合视角

用仓库历史做量化验证：统计“同一提交中被同时修改的文件/模块对”，共变频率高说明耦合强（应放一起），共变为零说明可以拆。

可用工具：Git 日志分析（如 code-maat 类脚本）、模块依赖图（jdeps、dependency-cruiser）。

组织视角

康威定律：系统结构必然映射组织沟通结构。反向操作（Inverse Conway Maneuver）是先调整团队与职责，再让系统成形。

判断要点：一个服务应由一个团队端到端负责（含值班与容量），如果需要两个团队共同修改同一服务才能完成需求，说明边界划错了。

拆分收益验证清单

拆之前回答：

拆完后哪些发布冲突会消失？（说不出即无收益）
谁负责这个服务？值班、性能、容量、SLA 是否有主。
数据归属是否清晰？每张表是否只有一个写入方。
跨服务调用会不会变成同步长链？（链路深度 > 3 需要重新审视边界）
需要什么基础设施支撑？（契约测试、追踪、灰度发布）

常见误区

误区	修正
只看领域模型不看团队	语义正确但两个团队共管，仍会持续冲突
只看 DDD 术语表不看变更历史	纸面边界与真实耦合不一致
把共享工具库当边界	库不提供服务语义，容易变成共同耦合点
用数据库表数量当服务数量	表是存储细节，不是能力
边界一次定终身	定期复核共变与调用链，边界需要演进

延伸阅读

Eric Evans《领域驱动设计》第 14 章
Mel Conway 原始论文与《Team Topologies》（Skelton & Pais）
Sam Newman《Building Microservices》第 2 章