服务建模

一、服务建模的第一性原理

1.1 复杂性不可消除，只能被管理

软件系统的本质不是代码，而是对业务复杂性的承载与约束。

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

1.2 边界是复杂系统的核心

在复杂系统中，真正重要的不是模块内部，而是：

没有清晰边界的系统，复杂性会指数级增长。

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

1.3 架构必须允许演进

因此：

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

二、服务建模的认知分层（稳定度模型）

为避免"知识混杂"，本文将服务建模拆分为四个稳定度层级：

服务建模认知层级├─ 第一性原理（最稳定）│  ├─ 复杂性管理│  ├─ 边界优先│├─ 架构哲学│  ├─ 低耦合 / 高内聚│  ├─ 演进式设计│├─ 架构模式│  ├─ Bounded Context│  ├─ 聚合（Aggregate）│  ├─ 六边形 / 整洁架构│  ├─ 绞杀者模式│└─ 工程策略（不稳定）   ├─ Saga   ├─ 事件溯源   ├─ 报表方案

👉 阅读与实践时，应优先掌握上层，再选择下层策略。

三、什么是"好服务"

3.1 好服务的本质标准

松耦合

高内聚

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

四、服务建模的三种视角（决策模型）

服务建模常见有三种切入方式，但它们的稳定性不同。

4.1 三种视角对比

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

4.2 核心结论

👉 技术应服务于业务边界，而非反之。

五、Bounded Context：服务建模的核心抽象

5.1 Bounded Context 的本质

Bounded Context（限界上下文）是：

👉 BC 是认知边界，不是部署单元。

5.2 Bounded Context 与 Service 的关系

场景说明
1 BC → 1 Service理想状态
1 BC → N Service演进或扩展阶段
N BC → 1 Service早期或过渡阶段

👉 不要教条化"一对一"映射。

六、业务逻辑的组织方式

6.1 架构哲学：依赖反转

这类架构包括：

👉 它们的本质都是：保护业务核心。

6.2 事务脚本 vs 领域模型

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

👉 不要在简单系统中过度设计。

七、聚合：一致性的边界

7.1 聚合的目的

聚合不是为了建模"对象"，而是为了：

聚合根是：

7.2 聚合设计的"张力"

👉 聚合设计永远是权衡问题。

八、领域事件：解耦的协议

8.1 领域事件的本质

领域事件表示：

领域中已经发生、且不可逆的事实

👉 事件是跨边界协作的语言。

九、从单体到服务：演进式拆分

9.1 为什么不要过早拆分

👉 先单体，后服务是理性选择。

9.2 绞杀者模式的哲学

👉 演进优于革命。

十、服务拆分的多维决策模型

服务拆分维度├─ 业务维度│  ├─ 子域│  ├─ 业务能力│├─ 变化维度│  ├─ 变化频率│  ├─ 生命周期│├─ 非功能维度│  ├─ 性能│  ├─ 可靠性│  ├─ 安全│└─ 组织维度   ├─ 团队边界   ├─ 责任归属

👉 单一维度无法得出合理拆分结论。

十一、数据、一致性与事务

11.1 核心原则

11.2 可选策略（非必选）

👉 架构设计的最高境界是避免问题，而非解决问题。

十二、组织与架构的协同

12.1 Conway 定律视角

12.2 责任模型

👉 技术架构本质上是社会系统设计。

十三、总结

关联内容（自动生成）