服务建模

概述

服务建模是业务建模成果向服务架构的映射过程。

业务建模解决"业务世界如何被理解与结构化"，服务建模在此之上解决：

识别出的业务边界，如何转化为可独立部署、演进和治理的服务单元？

服务建模不是重新发明业务模型，而是在业务模型的约束下做出服务设计决策。

本质

软件系统的核心难题不是技术实现，而是对业务复杂性的承载与约束：

服务建模 = 对复杂性进行分区与封装的过程

微服务的本质不是"服务很多"，而是边界清晰。

核心原则

边界优先原则

服务边界必须来自业务边界，而非技术边界：

演进优先原则

业务认知在初期一定是不完整的，早期模型几乎必然是"错的"：

好的服务建模不是一次性设计，而是允许被逐步修正的设计

先单体，后服务是理性选择——过早拆分会将不成熟的边界固化。

服务质量标准

维度描述
松耦合服务对外部世界的认知越少越好，只依赖稳定契约
高内聚一个服务只解决一类相关问题，行为围绕同一业务目标

高内聚是边界正确的结果，而非额外设计。

服务边界的识别

三种建模视角

服务建模有三种切入方式，稳定性不同：

视角稳定性适用阶段风险
业务能力高全周期低
用例中初期探索中
技术能力低特定场景高

长期稳定的架构应以业务能力为核心。技术应服务于业务边界，而非反之。

业务边界到服务边界的映射

业务建模中识别的语义边界（如 DDD 中的 Bounded Context）是服务边界划分的依据，但映射关系并非一对一：

场景说明
1 个语义边界 → 1 个服务理想状态
1 个语义边界 → N 个服务演进或扩展阶段
N 个语义边界 → 1 个服务早期或过渡阶段

不要教条化"一对一"映射。语义边界是认知边界，服务边界是部署单元，两者粒度由当前阶段决定。

服务拆分的多维决策模型

单一维度无法得出合理的拆分结论，需综合多个维度：

服务拆分维度├─ 业务维度│  ├─ 子域归属│  ├─ 业务能力独立性│├─ 变化维度│  ├─ 变更频率│  ├─ 生命周期差异│├─ 非功能维度│  ├─ 性能与扩展需求│  ├─ 可靠性要求│  ├─ 安全隔离需求│└─ 组织维度   ├─ 团队边界对齐   └─ 责任归属清晰

服务内部的业务逻辑组织

依赖反转原则

服务内部结构的核心原则是保护业务核心不受外部技术污染：

六边形架构、整洁架构本质上都是这一原则的体现。

业务逻辑复杂度与组织策略

模式适用场景特点
事务脚本简单业务过程式、低成本
领域模型复杂业务状态与行为内聚、可演进

不要在简单系统中过度设计。领域模型的引入成本应与业务复杂度匹配。

一致性边界对服务设计的影响

业务模型中的一致性边界直接约束服务的事务设计：

架构设计的最高境界是避免跨边界事务，而非解决它。

跨服务协作

协作的本质

跨服务协作是不同语义世界之间的翻译问题。

每个服务拥有自己的内部模型，跨服务调用必须通过明确定义的契约，而非直接访问对方的内部结构。

协作模式

模式特点适用场景
同步调用强依赖、即时响应查询、需要即时反馈的操作
异步事件松耦合、最终一致跨域状态同步、副作用传播
Saga补偿式分布式事务跨服务业务流程

异步事件是跨边界协作的首选——服务只需发布"已发生的事实"，下游自主订阅，耦合最小。

演进策略

从单体到微服务

过早拆分的代价：

演进路径：

单体验证业务模型 → 识别稳定边界 → 按边界逐步拆分

绞杀者模式

演进优于革命。重要的是每次拆分都基于已验证的业务边界。

组织与架构的协同

Conway 定律揭示了服务建模与组织的深层关系：

系统结构是组织沟通结构的映射

这意味着：

服务边界的合理性，最终会体现在团队自治程度上。

关联内容（自动生成）