vibe-coding-cn/docs/concepts/system-building.md

<a id="concept-system-building"></a>

# 系统构建方法

> 自顶向下、自底向上与分而治之的组合使用。

软件工程中的自顶向下、自底向上和分而治之，是三种经典的问题分析与系统构建方法。

<a id="concept-system-building-一自顶向下先看整体再拆细节"></a>
### 一、自顶向下：先看整体，再拆细节

**自顶向下**的核心思路是：先明确系统整体要做什么，再逐层拆分成子系统、模块、类、函数，最后落实到具体代码实现。

比如要开发一个在线购物系统，采用自顶向下的方法时，通常会先问：

这个系统的总体目标是什么？
它需要支持哪些核心业务？
整体架构应该如何划分？

然后再逐步拆解：

在线购物系统
→ 用户模块、商品模块、购物车模块、订单模块、支付模块、物流模块
→ 订单模块
→ 创建订单、取消订单、查询订单、订单状态流转
→ 创建订单函数
→ 参数校验、库存检查、价格计算、订单保存、消息通知

这种方法的优势是**全局结构清晰**。系统从一开始就有比较明确的架构边界，模块之间的关系也更容易统一规划。对于需求比较明确、规模较大的系统，例如银行核心系统、企业 ERP 系统、政务平台、基础设施平台等，自顶向下非常常见。

它的缺点是，如果一开始对需求理解不准确，高层设计可能会出现偏差，后续细节实现时就会频繁返工。因此，自顶向下适合需求相对清楚、业务边界比较稳定的场景。

<a id="concept-system-building-二自底向上先做组件再组系统"></a>
### 二、自底向上：先做组件，再组系统

**自底向上**的核心思路是：先从基础能力、底层组件、工具模块开始建设，再逐步组合成更大的功能和完整系统。

比如还是开发在线购物系统，采用自底向上的方法时，可能会先实现：

日志组件
配置管理组件
数据库访问组件
缓存组件
权限校验组件
消息队列封装
通用异常处理模块
支付 SDK 封装

当这些基础组件逐渐稳定后，再用它们组合出商品服务、订单服务、支付服务等业务模块，最终形成完整系统。

这种方法的优势是**复用性强、基础能力扎实**。团队可以不断沉淀通用模块，后续开发新功能时就不需要重复造轮子。对于已有技术平台、组件库、框架体系的团队来说，自底向上很自然。

它也适合需求还在演化的项目。因为业务目标可能一开始并不完全清楚，但团队可以先建设确定性较高的底层能力，等需求逐渐明确后再组合成业务系统。

它的风险是，如果只关注底层组件而缺乏整体目标，可能会出现“组件很多，但系统拼不起来”的问题。也就是说，自底向上容易造成局部能力很强，但整体架构不够统一。

<a id="concept-system-building-三分而治之把复杂问题拆成小问题"></a>
### 三、分而治之：把复杂问题拆成小问题

**分而治之**的核心思想是：面对复杂问题时，不直接一次性解决整体，而是把它拆成若干相对独立、规模更小的问题，分别解决后再组合起来。

它更像是一种通用的问题处理原则，不只是软件工程中的系统构建方法，也广泛存在于算法设计、项目管理、组织协作中。

比如开发一个推荐系统，可以把问题拆成：

数据采集
用户画像
商品画像
召回算法
排序算法
特征工程
模型训练
在线推理
效果评估

每个部分都可以由不同团队或不同模块独立推进，最后再集成为完整的推荐系统。

分而治之的优点是**降低复杂度**。一个大问题往往难以直接理解和实现，但拆成多个小问题后，每个小问题的目标更清晰、测试更容易、维护成本也更低。

不过，分而治之的关键在于“如何拆”。如果拆分边界不合理，就会导致模块之间耦合严重、接口混乱、集成困难。好的拆分应该尽量做到高内聚、低耦合：每个模块内部职责集中，模块之间通过清晰接口协作。

<a id="concept-system-building-四三者之间的关系"></a>
### 四、三者之间的关系

这三种方法并不是完全独立的。

**自顶向下**强调从整体到局部，通常会用到分而治之。因为从系统目标拆到模块、从模块拆到函数，本质上就是在分解问题。

**自底向上**强调从局部到整体，也可以结合分而治之。先分别解决多个基础能力或局部问题，再逐步组合成更复杂的系统。

**分而治之**则更像是底层思想，它既可以服务于自顶向下，也可以服务于自底向上。

可以简单理解为：

自顶向下回答的是：**从哪里开始设计？**
自底向上回答的是：**从哪里开始实现？**
分而治之回答的是：**如何降低复杂度？**

<a id="concept-system-building-五举一个综合例子"></a>
### 五、举一个综合例子

假设要开发一个企业内部审批系统。

采用自顶向下时，团队会先定义系统整体架构：

审批系统
→ 表单管理
→ 流程管理
→ 权限管理
→ 通知管理
→ 审批记录
→ 数据报表

然后继续拆解流程管理：

流程定义
流程发起
节点审批
流程转交
流程撤回
流程归档

采用自底向上时，团队可能会先建设一些基础能力：

用户身份认证
角色权限模型
表单渲染引擎
消息通知组件
流程状态机
审计日志组件
数据库访问层

这些组件稳定后，再组合成完整的审批业务。

而分而治之贯穿整个过程：无论是把审批系统拆成表单、流程、权限、通知，还是把流程引擎拆成状态流转、节点规则、审批人计算、超时处理，都是在通过拆分降低复杂度。

<a id="concept-system-building-六实际项目中如何选择"></a>
### 六、实际项目中如何选择

如果项目目标清晰、业务边界稳定、系统规模较大，可以优先采用**自顶向下**，先做好架构设计和模块划分。

如果团队已有大量基础组件，或者项目需求还在逐步演化，可以更多采用**自底向上**，先沉淀稳定的底层能力，再支撑业务扩展。

如果问题本身很复杂，无论采用哪种方向，都应该使用**分而治之**，把复杂系统拆成更容易理解、开发、测试和维护的部分。

在真实软件工程中，最常见的做法是：
先用**自顶向下**明确系统目标和架构边界；
再用**分而治之**拆分模块和任务；
同时用**自底向上**建设可复用组件和基础能力；
最后通过迭代开发不断调整设计。

所以，这三种方法不是“选一个、排斥另外两个”，而是从不同角度帮助我们管理复杂度、组织代码和构建系统。