第2章 画好手术刀线：服务边界从哪切

第2章 画好手术刀线：服务边界从哪切

本章继续跟那台商城单体。第 1 章我们确诊了它该拆，也明白了要"边迁边瘦身"。现在问题来了：到底从哪里下第一刀？ 刀线画对了，拆出的每个器官都独立供血；画错了，拆出来的是一堆串在一起的"分布式单体"，比原来还难养。本章把刀线这门手艺讲到烂熟。

服务边界是微服务里最考验判断力的活。它没法用自动化工具一键完成，也没有标准答案——三个团队给同一台系统画边界，可能画出三份都"说得通"的方案。本章不给你一份馊主意式的模板，而是给你三把尺子：限界上下文决定切口落在业务语义上，高内聚低耦合决定切口深浅，康威定律告诉你组织这张图和系统这张图天然对不上——而 API 契约负责把缝合面焊牢。

一条主线

还是那台商城：它有买家、卖家、商品、订单、支付、库存一堆能力。我们拿着"业务事件"这张地图去找"哪些话术必须成对出现、哪些数据永远一起变化"，把咬合最紧的能力捏成一团，把切得开的能力划成两个器官。本章每一站都是在给这台商城试画刀线。

沿途站点

2.1 限界上下文：确定切口与入路——讲清 DDD 里的限界上下文（Bounded Context）怎么当一个"业务语义的密封舱"：为什么"订单"在买家眼里和仓库眼里是两个东西，以及怎么用它定位一个服务该管的边界。

2.2 高内聚低耦合的分割刀法——把"高内聚低耦合"从口号变成可操作的刀法：怎么衡量内聚、怎么识别不自然的耦合（如共享表、隐式依赖），并给出一套"先聚后切"的实操顺序。

2.3 康威定律与 API 优先契约——这一站接住一个常被忽视的事实：系统的边界常常是由组织结构焊出来的。我们讲康威定律怎么帮你（而不是害你）画边界，并用 API 优先设计与契约把缝合面定下来，防止两个服务私下改接口把对方打崩。

拐点与结论

本章最值钱的认知转折是：服务边界不是技术问题，是语义与组织问题。代码、框架、数据模型都只是执行层面的声音，真正决定一刀切得准不准的，是"这一团业务到底算不算一件事"以及"是谁在长期维护它"。很多拆失败的架构，不是没拆，而是拆在了一个错误的地图上——刀线画在"技术分层"上，而不是"业务语义"上。

这一章最容易踩的三个坑

画服务边界是"道理都懂、一画就错"的重灾区，先把最常见的三个坑点出来：

1. 把刀线画在技术分层上，而不是业务语义上。按"Controller 层"“Service 层”去切，切出来的其实是一堆分层组件，业务还是一锅粥。刀线该落在"哪个团队的什么能力算一件事"，落在限界上下文上。
2. 为了小把小到极致，拆到失去边界。微服务哭诉的终局不是拆不动，而是拆太碎——几百个服务互相调用打成肉搏，连"这东西归谁"都查不清。粒度不是越小越好，是"恰好能独立供血、赔偿得过来"才算数。
3. 只画静态边界，不钉契约。边界画得再漂亮，不把"两个服务怎么互相说话、接口长什么样"用契约定下来，一上线就会被私改接口打回原形。边界是刀，契约是缝合线，缺一不可。

把这三个坑记在心上，再进站点看怎么一一绕开。

读完你应该

• 能用限界上下文给一个系统的能力划分边界，并说清理由
• 会评估一段模块的内聚度，识别共享表、隐式依赖等不自然耦合
• 能说明康威定律为什么既是"因"也是"果"，并利用它指导组织配合
• 会用 API 优先的方式来定义服务间契约，减少随意改接口
• 画出一张属于一台业务的"服务边界草图"

下一章的接力

刀线画好了，两个器官之间要"说话"。第 3 章就把这层关系接通——服务间该用同步调用还是异步消息？API 网关在中间挡什么？服务都动态扩缩了，客户端怎么找到它们？这些问题，是"切得开"之后"活得起来"的关键。