鲁班 - 系统设计大全

2.4 从业务模型到系统边界

一句话

系统边界不是 “按组织切” 也不是 “按表切”，而是三条线的交集：一致性边界（哪些数据必须一起改）、变更频率（哪些总是一起改）、团队边界（谁能独立发布）；三条线对不上时，先看流程的跨边界比例。

三种切法

切法 依据 问题
按组织 部门归属 组织调整即失效；跨部门流程被切碎
按实体/表 数据库表 一个业务动作要改多张表 → 跨服务事务
按能力 + 一致性边界 业务能力 + “必须同事务的聚合” 需要先做领域建模（成本前置）

推荐组合：能力定粗边界 → 聚合定细边界 → 团队边界做校验（与 29.3 聚合与事务边界 对齐）。

实测：跨边界比例判断 “切得对不对”

把 2.2 的流程活动映射到 2.1 的能力边界，再统计流程流转：

指标 结果
能力总数 / 已映射 9 / 7（2 个未映射）
流程流转总数 5
跨边界流转 4（80%）
边界间调用对 订单→库存、库存→履约、风控→履约、履约→财务
最忙边界 履约中心（被 3 条流转碰到）

判据：跨边界 > 60% 说明边界的切法与流程不一致——本例 80%，意味着 “几乎每一步都要跨系统”，延迟、事务、故障传播都会放大。整改方向不是 “加接口”，而是按流程重组边界（例如把 “锁库存 + 拣货” 合成履约域，或把 “审核信用” 前移到下单前）。

cross = [(a,b) for a,b in flow if act2b[a] != act2b[b]]
ratio = len(cross)/len(flow)
print("跨边界比例:", f"{ratio:.0%}", "→", "需重组" if ratio > 0.6 else "可接受")

三条判定规则

规则 问法 结论
一致性 这两块数据必须同一事务改吗？ 是 → 同一边界
变更频率 它们总是一起改吗？ 是 → 同一边界
团队 能独立发布/回滚吗？ 不能 → 边界太细或依赖未理清

反模式

反模式 后果
按部门切边界 跨部门流程变成跨系统调用，延迟与事务成本翻倍
按表切边界 一个业务动作改多张表 → 分布式事务
边界太细（每实体一服务） 调用链长、故障点多
边界太粗（一个 “核心服务”） 无法独立演进，团队互相阻塞
不做跨边界统计 不知道 “切得对不对”，只能凭感觉
边界与团队不一致 康威定律反噬：代码结构向组织漂移

三条铁律

🔑 先定一致性边界，再谈服务拆分；一致性边界错了，后面全错。

🔑 跨边界比例 > 60% 就要重组，不是加接口。

🔑 边界必须能被团队独立发布；不能独立发布说明粒度或依赖有问题。

自检

Q1 为什么 “按表切边界” 会导致分布式事务？

▸ 答案：因为一个业务动作通常要改多张表（下单要写订单、扣库存、记流水）。按表切意味着这些表分属不同服务，本地事务变成跨服务事务，只能靠 2PC/Saga 补偿。按 “一致性边界（聚合）” 切，则一个动作在一个服务内完成。

Q2 跨边界比例 80% 说明什么？该怎么改？

▸ 答案：说明边界切法与业务流程不一致：几乎每一步都要跨系统，延迟叠加、事务复杂、故障传播。改法不是 “加 RPC”，而是按流程重组：把高频连续流转的活动放进同一边界（如锁库存 + 拣货 → 履约），或把可前移的步骤（信用审核）提前到流程入口。

Q3 “最忙边界” 为什么值得关注？

▸ 答案：因为它会成为耦合中心与故障中心：所有流转都经过它，它的可用性决定全链路；它的变更会牵动所有上游。本例 “履约中心” 被 3 条流转碰到，若继续加职责，就会退化成 “什么都做的核心服务”。

Q4 能力边界与限界上下文对不上时，信谁？

▸ 答案：以限界上下文为准来做代码边界，以能力为准来做组织与投资决策。两者对不上通常说明 “业务语言与模型语言不一致”——要么能力拆得太细（应合并），要么模型漏了某个上下文（应补）。这个差异本身就是重要信号。

Q5 边界确定后，第一件要落地的事是什么？

▸ 答案：把边界写进构建：模块/服务目录、依赖规则（见 27.3 模块边界与依赖规则）、数据 owner（每张表只有一个写方）。没有这三样，边界只存在于架构图里，三个月后就会被 “临时需求” 打穿。

Q6 什么时候应该 “合并边界” 而不是 “拆”？

▸ 答案：当两块数据必须同一事务、或总是一起变更、或跨边界调用比例极高时。拆分的收益（独立演进）小于成本（分布式事务、延迟、运维）时，就该合并。判据是 “拆开后，一次业务变更要改几个服务”。

Q7 怎么证明 “边界划分有效”？

▸ 答案：三个可测指标：跨边界流转比例（应下降）、单次变更影响的边界数（应为 1–2）、独立发布成功率（能只发一个边界且不回滚）。三者都改善，才说明边界真的立住了；只看 “服务数量变多” 是自欺。

关联