Pasule Article Brief

先掌握这篇文章的结构，再开始往下读

从一个小系统开始，理解模块怎么拆、边界怎么定、接口怎么收，避免项目越写越乱。

从一个很小的需求开始模块划分的第一个标准：职责是否单一第二个标准：依赖方向要稳定第三个标准：接口要为变化留空间

预计阅读

3 min

按当前正文长度估算

目录规模

7 / 7

一级章节 / 总锚点

最后更新

2026-04-08

系列 1/2

阅读难度

beginner

架构设计

阅读完成度 0%

Reading For

适合谁读

适合刚开始搭技术知识树、希望先抓住主线概念的读者。这篇内容会重点围绕 模块边界 / 依赖方向 / 设计演进 展开。

Takeaways

你会拿到什么

  • 从一个小系统开始，理解模块怎么拆、边界怎么定、接口怎么收，避免项目越写越乱。
  • 你可以顺着 从一个很小的需求开始 / 模块划分的第一个标准：职责是否单一 / 第二个标准：依赖方向要稳定 这条目录主线快速建立结构感。
  • 读完后可以继续进入《微服务架构设计原理与最佳实践》，把当前主题延伸成连续阅读。

软件架构设计入门：从拆模块到定边界

🧭 本文想解决的问题

  • 为什么很多项目不是功能难，而是越写越乱
  • 怎么判断一个模块边界是不是合理
  • 如何在早期就把耦合风险压下来

从一个很小的需求开始

假设我们要做一个“个人收藏夹”系统，用户可以：

  • 登录
  • 收藏文章
  • 给收藏打标签
  • 搜索和筛选收藏内容

很多项目在这个阶段就会直接开干，把所有逻辑都堆在一个服务里。短期看很快，长期看代价很大：

  • 登录逻辑和收藏逻辑耦在一起
  • 搜索需求一来，数据访问层迅速变复杂
  • 后面要加同步、分享、推荐时，改动范围会越来越大

模块划分的第一个标准：职责是否单一

最简单的拆分方法不是按文件类型，而是按“这个模块到底负责什么”。

例如这个小系统可以先拆成：

  • auth：只处理身份认证和登录状态
  • bookmark：只处理收藏的增删改查
  • tag：只处理标签归类
  • search：只处理查询与筛选逻辑

这样拆的好处是：

  • 你能明确每个模块的输入输出
  • 测试会更容易写
  • 后面重构时不容易牵一发而动全身

第二个标准：依赖方向要稳定

一个常见错误是：

  • bookmark 依赖 search
  • search 又反过来调用 bookmark

这类双向依赖在小项目里也许能跑，但只要需求继续增长，就会让结构迅速失控。

更健康的方式是：

  • 核心数据模块向下沉
  • 组合逻辑向上提
  • 搜索读取收藏数据，但不反向控制收藏模块

简单说：

底层模块提供能力，上层模块负责组织能力。

第三个标准：接口要为变化留空间

接口设计的目标不是“现在能用”，而是“之后变化时，不必把整条链重写”。

例如收藏模块提供的接口，如果一开始就只返回最底层数据库结构，后面你想：

  • 加排序
  • 加推荐状态
  • 加归档标记

就会让调用方一起跟着改。

更稳的方式是：

  • 对外暴露语义明确的返回结构
  • 把数据库字段和业务字段分开思考
  • 让调用方依赖业务语义，而不是表结构细节

什么时候该继续拆，什么时候先别拆

很多人一学架构就容易过度设计。这里有个实用判断标准：

如果一个模块已经同时满足下面两条，就值得拆：

  1. 它承担了两种以上明显不同的职责
  2. 它的变更频率和依赖方不一致

反过来，如果只是代码量多，但职责其实单一，就未必要急着拆。

一个更实用的检查清单

你可以用下面的问题快速判断当前结构是不是健康：

  • 这个模块一句话能不能说清楚职责？
  • 调用它的人，是否必须知道它的内部细节？
  • 改它时，会不会波及一大片无关功能？
  • 这个模块的测试，是不是越来越难写？

如果这几个问题里有两个以上答不上来，就说明边界已经开始模糊了。

结语

好的架构不是把系统拆得多漂亮，而是让系统在变化中仍然可维护。

所以真正值得先练的，不是画复杂架构图，而是把这三件事练熟：

  • 职责划分
  • 依赖方向
  • 接口边界

把这三件事做好，小项目会更清晰，大项目也更容易演进。

读完之后可以去哪里

回到文章档案