{"name":"服务建模","id":"软件工程-微服务-服务建模","content":"# 服务建模\n\n## 概述\n\n服务建模是**业务建模成果向服务架构的映射过程**。\n\n业务建模解决\"业务世界如何被理解与结构化\"，服务建模在此之上解决：\n\n> **识别出的业务边界，如何转化为可独立部署、演进和治理的服务单元？**\n\n服务建模不是重新发明业务模型，而是在业务模型的约束下做出**服务设计决策**。\n\n## 本质\n\n软件系统的核心难题不是技术实现，而是对**业务复杂性的承载与约束**：\n\n* 复杂性不可消除，只能被管理\n* 管理复杂性的核心手段是**边界**：模块之间的责任划分与协作协议\n* 没有清晰边界的系统，复杂性会指数级增长\n\n> **服务建模 = 对复杂性进行分区与封装的过程**\n\n微服务的本质不是\"服务很多\"，而是**边界清晰**。\n\n## 核心原则\n\n### 边界优先原则\n\n服务边界必须来自业务边界，而非技术边界：\n\n* 业务语义一致的能力应在同一服务内\n* 技术便利性不能成为划分服务边界的依据\n* 错误边界的代价极高，早期应保守而非激进\n\n### 演进优先原则\n\n业务认知在初期一定是不完整的，早期模型几乎必然是\"错的\"：\n\n> 好的服务建模不是一次性设计，而是允许被逐步修正的设计\n\n**先单体，后服务**是理性选择——过早拆分会将不成熟的边界固化。\n\n### 服务质量标准\n\n| 维度  | 描述                  |\n| --- | ------------------- |\n| 松耦合 | 服务对外部世界的认知越少越好，只依赖稳定契约 |\n| 高内聚 | 一个服务只解决一类相关问题，行为围绕同一业务目标 |\n\n高内聚是**边界正确的结果**，而非额外设计。\n\n## 服务边界的识别\n\n### 三种建模视角\n\n服务建模有三种切入方式，稳定性不同：\n\n| 视角   | 稳定性 | 适用阶段 | 风险 |\n| ---- | --- | ---- | -- |\n| 业务能力 | 高   | 全周期  | 低  |\n| 用例   | 中   | 初期探索 | 中  |\n| 技术能力 | 低   | 特定场景 | 高  |\n\n**长期稳定的架构应以业务能力为核心**。技术应服务于业务边界，而非反之。\n\n### 业务边界到服务边界的映射\n\n业务建模中识别的语义边界（如 DDD 中的 Bounded Context）是服务边界划分的依据，但映射关系并非一对一：\n\n| 场景               | 说明      |\n| ---------------- | ------- |\n| 1 个语义边界 → 1 个服务 | 理想状态    |\n| 1 个语义边界 → N 个服务 | 演进或扩展阶段 |\n| N 个语义边界 → 1 个服务 | 早期或过渡阶段 |\n\n不要教条化\"一对一\"映射。语义边界是认知边界，服务边界是部署单元，两者粒度由当前阶段决定。\n\n### 服务拆分的多维决策模型\n\n单一维度无法得出合理的拆分结论，需综合多个维度：\n\n```\n服务拆分维度\n├─ 业务维度\n│  ├─ 子域归属\n│  ├─ 业务能力独立性\n│\n├─ 变化维度\n│  ├─ 变更频率\n│  ├─ 生命周期差异\n│\n├─ 非功能维度\n│  ├─ 性能与扩展需求\n│  ├─ 可靠性要求\n│  ├─ 安全隔离需求\n│\n└─ 组织维度\n   ├─ 团队边界对齐\n   └─ 责任归属清晰\n```\n\n## 服务内部的业务逻辑组织\n\n### 依赖反转原则\n\n服务内部结构的核心原则是保护业务核心不受外部技术污染：\n\n* 业务逻辑不依赖外部技术实现\n* 外部（数据库、消息、API）通过适配器接入业务核心\n\n六边形架构、整洁架构本质上都是这一原则的体现。\n\n### 业务逻辑复杂度与组织策略\n\n| 模式   | 适用场景 | 特点        |\n| ---- | ---- | --------- |\n| 事务脚本 | 简单业务 | 过程式、低成本   |\n| 领域模型 | 复杂业务 | 状态与行为内聚、可演进 |\n\n不要在简单系统中过度设计。领域模型的引入成本应与业务复杂度匹配。\n\n### 一致性边界对服务设计的影响\n\n业务模型中的一致性边界直接约束服务的事务设计：\n\n* 一致性边界内的操作应在单个服务内完成\n* 跨服务操作必须接受**最终一致性**，而非分布式强一致\n* 跨边界的状态变更通过显式事件表达，而非共享状态\n\n> 架构设计的最高境界是**避免跨边界事务**，而非解决它。\n\n## 跨服务协作\n\n### 协作的本质\n\n跨服务协作是**不同语义世界之间的翻译问题**。\n\n每个服务拥有自己的内部模型，跨服务调用必须通过明确定义的契约，而非直接访问对方的内部结构。\n\n### 协作模式\n\n| 模式     | 特点           | 适用场景         |\n| ------ | ------------ | ------------ |\n| 同步调用   | 强依赖、即时响应     | 查询、需要即时反馈的操作 |\n| 异步事件   | 松耦合、最终一致     | 跨域状态同步、副作用传播 |\n| Saga   | 补偿式分布式事务     | 跨服务业务流程      |\n\n异步事件是跨边界协作的首选——服务只需发布\"已发生的事实\"，下游自主订阅，耦合最小。\n\n## 演进策略\n\n### 从单体到微服务\n\n过早拆分的代价：\n\n* 业务理解不成熟，边界会被固化为错误的设计\n* 后续修正成本等同于重写\n\n演进路径：\n\n> 单体验证业务模型 → 识别稳定边界 → 按边界逐步拆分\n\n### 绞杀者模式\n\n* 新功能不再进入旧系统，从边缘逐步替换\n* 旧系统自然萎缩，无需一次性迁移\n\n演进优于革命。重要的是每次拆分都基于已验证的业务边界。\n\n## 组织与架构的协同\n\nConway 定律揭示了服务建模与组织的深层关系：\n\n> 系统结构是组织沟通结构的映射\n\n这意味着：\n\n* 服务边界应与团队边界对齐，否则服务边界会被沟通成本侵蚀\n* 一个服务对应一个明确的责任主体\n* 技术架构本质上是**社会系统设计**\n\n服务边界的合理性，最终会体现在团队自治程度上。\n\n## 关联内容（自动生成）\n\n- [/软件工程/微服务/微服务.md](/软件工程/微服务/微服务.md) 微服务概述是服务建模的直接上下文，提供了微服务架构的核心概念与前置条件\n- [/软件工程/微服务/集成.md](/软件工程/微服务/集成.md) 跨服务协作模式（同步调用、异步事件、Saga）在集成文档中有具体实现说明\n- [/软件工程/微服务/服务治理/服务治理.md](/软件工程/微服务/服务治理/服务治理.md) 服务建模确定边界后，服务治理是直接的下游，负责边界内服务的运行时管理\n- [/软件工程/领域驱动设计.md](/软件工程/领域驱动设计.md) DDD 提供了语义边界、一致性边界等核心概念，是服务边界识别的主要方法论来源\n- [/软件工程/架构/系统设计/业务建模.md](/软件工程/架构/系统设计/业务建模.md) 业务建模是服务建模的直接上游，服务边界必须来自业务边界\n- [/软件工程/架构/系统设计/架构设计.md](/软件工程/架构/系统设计/架构设计.md) 服务建模的输出直接构成架构设计的结构决策依据\n- [/软件工程/架构/系统设计/分布式/分布式事务.md](/软件工程/架构/系统设计/分布式/分布式事务.md) 文档中的 Saga、最终一致性、跨服务事务策略在分布式事务文档中有完整的理论支撑\n- [/软件工程/架构/演进式架构.md](/软件工程/架构/演进式架构.md) 演进式架构与服务建模的演进观共享同一前提：先单体验证边界，再逐步拆分\n- [/数据技术/数据架构.md](/数据技术/数据架构.md) 服务边界的确定直接影响数据的分布与所有权划分，与数据架构设计密切相关\n","metadata":"tags: ['分布式系统', '服务建模', '数据技术', '架构设计', '业务建模']","hasMoreCommit":false,"totalCommits":7,"commitList":[{"date":"2026-03-18T11:29:52+08:00","author":"MY","message":"docs(微服务): 重构服务建模文档结构并优化内容表述","hash":"31b1d17ff0099f07f4e19dc1eb9a8c7af09707be"},{"date":"2026-02-12T14:07:03+08:00","author":"MY","message":"doc: 整理标签","hash":"290b3e8ad18f48832ac282290238d020fc030a88"},{"date":"2026-01-09T15:04:16+08:00","author":"MY","message":"docs(微服务): 完善服务建模文档内容并新增相关图片资源","hash":"b1758654815ea6d56d4a6c7432384b30c09a8cf5"},{"date":"2024-11-25T15:59:06+08:00","author":"MY","message":"📦微服务","hash":"c8734b29d256e1b4841404e738ec87270d58d3f2"},{"date":"2024-11-25T14:06:28+08:00","author":"MY","message":"📦微服务","hash":"984b0cab1bfa9822163a0947a83e9fea875c581a"},{"date":"2020-06-18T16:38:09+08:00","author":"MY","message":"更新 微服务","hash":"e9ad88d1d8b4c922ef0b61ccef6ba19ee7994201"},{"date":"2020-02-09T16:38:48+08:00","author":"MY","message":"微服务增加服务建模","hash":"006340b827ab5d777ba44a3d40ba1318a0d98ca6"}],"createTime":"2020-02-09T16:38:48+08:00"}