基于架构的软件开发（ABSD）：别再“先写代码，后补架构”基于架构的软件开发（ABSD）：别再“先写代码，后补架构” A

基于架构的软件开发（ABSD）：别再“先写代码，后补架构”

ABSD（Architecture Based Software Design）想解决的问题是：
别再“先堆需求 + 先写代码，最后才想起要有个架构”。

它给你一套实操感很强的思路：
需求驱动 + 四大基石 + 六步流程 + 持续演进。
这一篇用一线开发 / 准架构师能立即上手的方式，把 ABSD 拆清楚。

一、从马斯洛到架构：为什么一定要“需求驱动”？

ABSD 先把需求分了层，有点类似马斯洛需求层次理论：

生理层：业务功能需求
- 没有业务功能，就没有软件，架构再优雅也只是 PPT。
- 核心问题：这个系统到底要帮业务干什么？
安全 / 社交层：质量与非功能性需求
- 高可用、扩展性、性能、容错、安全性等；
- 对应业务侧的“业务不能挂”“高峰不能崩”“体验不能太差”。
尊重 / 自我实现层：限制与企业策略
- 行业 / 法规约束（如金融监管、合规要求）；
- 企业架构团队的“统一技术策略”：如必须开源、必须可上云、必须统一监控链路等。

ABSD 的第一个观念就是：

架构不是从“我想用啥技术”开始，而是从这些层次化的需求出发。

二、ABSD 的四大基石：功能分解、架构风格、模板复用、递归演进

ABSD 的核心，用一句话概括是：

用功能分解拆问题，用架构风格定形态，用模板复用加速落地，用递归演进逼近目标。

1. 功能分解：从“大需求”拆到“合适粒度模块”

做法是：

先从需求（用例）出发，而不是从技术栈出发；
把相近的一组功能聚在一个模块里；
控制模块尺寸，做到高内聚、低耦合。

可以借助常见设计原则：

SOLID 五大原则（单一职责、开闭、里氏替换、接口分离、依赖倒置）；
还有高内聚 / 低耦合的一些更细粒度原则（如稳定依赖、稳定抽象等）。

2. 架构风格：给模块“选一件合适的外套”

模块划完后，不能只停在“有个名字”，还要决定：

它属于什么风格：
- 分层、主程序-子程序、面向对象；
- 事件驱动、批处理、管道过滤器；
- 黑板 / 仓库 / 规则引擎 / 虚拟机等。

风格并不是“高大上的标签”，而是帮你回答：

这个模块怎么处理数据流？
怎么跟别的模块通信？
对应什么样的性能 / 可用性 / 扩展性特点？

3. 软件模板：别什么都从零写一遍

ABSD 强调大量使用“模板”（Template）：

可以是架构模板：一套通用的分层架构图 / 组件关系图；
也可以是实现模板：可复用的库、通用模块、脚手架工程。

思路是：

先选好风格 → 再找该风格下成熟的模板 → 再做适配与剪裁；
少造轮子，把时间花在业务差异化上。

4. 递归 / 迭代：一层层逼近，而不是“一步到位”

这是 ABSD 和很多“只画一张大图就结束”的方法论最大的不同：

每一轮都做：功能分解 → 选风格 → 用模板 → 设计 / 实现 → 再分解……
自顶向下不断细化：
- 系统 → 子系统 → 构件（Component）→ 包 / 类 → 代码；
- 每一层都可以再“跑一遍”四大基石。

长期看，你得到的不是一次性“大设计”，而是一套可演进的架构资产。

三、ABSD 六步流程：从需求库到演进闭环

在方法层面，ABSD 把工作拆成了一个六步循环，并且强调“大小两个回路”：

收集与管理需求
- 建一个统一的需求库（Excel / 文档 / 工具都行）；
- 功能 + 非功能 + 限制都要进来。
需求分解与初始设计
- 用“小鸡啄米、小鸡快跑”的思路：
  - 不用一上来就搞超级复杂的整体设计；
  - 先把相关的类 / 模块大致画出来，再分组。
生成类图和模块分组
- 先“想到什么类就画什么类”，不怕多、不怕错；
- 再按职责 / 相似度分组，把类收敛成模块；
- 这一步就已经有了最初版的 UML 类图 / 包图。
架构建模：选风格 + 选模板
- 基于已有类 / 模块，挑合适的架构风格：
  - 比如流式告警用“管道过滤器”，夜间批结算用“批处理”；
- 在对应风格下找模板（参考架构 / 代码骨架），确定构件边界与关系。
实现与构建库复用
- 引入“构建库”（Component Library）的概念：
  - 把可复用构件 + 模板都沉淀进库；
- 实现时优先从构建库里“拿”，不够再开发；
- 实现后的新构件也要反向补进构建库。
演化与再设计
- 需求不会停，ABSD 认为“唯一不变的是架构师本人，需求永远在变”：
  - 新需求来 → 先做演化计划 → 再看哪些构件需要替换 / 新增；
  - 仍然优先从构建库找；
  - 调整构件交互关系、接口，再重新组装和测试。

两个回路：

小回路：设计 ↔ 复审（早暴露问题、早修正）；
大回路：实现 ↔ 新需求 ↔ 架构演进（持续迭代，避免一次性大翻修）。

四、金融证券案例：一个“不懂证券的银行”怎么落地 ABSD

书里用了一个金融行业的案例，帮你把 ABSD 从“理论”拉回“实战”。

业务背景

一家传统银行，国内从未做过证券业务，但在海外拿到了证券牌照；
想做一套“支持红马甲现场交易 + 网银查询的证券系统”；
同时要满足：
- T+1 日终分红派息结算；
- 接入银行监管 / 核算系统；
- 99.95% 的高可用要求（接近银行核心系统标准）。

1. 需求分析：从“不会证券”到“抽象出领域和渠道”

用 ABSD 思路做需求分解后，可以抽出几层：

领域层（核心域）
- 证券交易（订单、持仓、结算等）；
- 分红派息结算逻辑；
- 与交易所 / 银行监管对接的领域规则。
渠道层
- 对接证券交易所的渠道（现场交易、前置机）；
- 对接银行监管 / 大型核心系统的内部渠道；
- 未来再加网银渠道。

这里用到了设计原则（例如单一职责、依赖倒置等）：

将“对外证券渠道”和“对内监管渠道”拆成不同通道；
让领域层尽量“被依赖而不主动依赖外部系统”，减少受外部变化牵连。

2. 设计阶段：选风格 + 模板拼装

针对不同需求选不同风格：

日间交易：流式 + 管道过滤器
- 要紧跟交易所节奏、快速处理订单流；
- 用管道式处理链：校验 → 风控 → 路由 → 持久化……
夜间 T+1 分红派息：批处理
- 有整晚时间跑批，适合大批量离线计算。
数据共享：仓库 / 数据库风格
- 统一持久化用户证券持仓、历史交易、收益情况等。

再看对接外部系统时怎么用模板：

对接银行核心系统：
- 复用已有的“交易监管网关”、“夜间核算网关”等模板；
- 只做少量适配，把“流水交易”变成“证券交易”。
对接证券交易所：
- 交易所本身提供多种“前置机模板”；
- 在此基础上做少量改造，接入自己的领域接口。

3. 迭代与演进：先上线“能交易”，再补“网银”等

ABSD 不鼓励“一开始什么都做完”，而是：

第一版：
- 目标：让“红马甲能正常交易 + T+1 分红派息 + 银行监管对接 + 满足 99.95% 高可用”；
- 网银等非关键功能推迟到下一轮演进。
第二版：
- 快速迭代，引入网银查询渠道，与现有领域层对接。

整个过程：
需求 → 分解 → 风格 & 模板 → 实现 → 复审 → 再需求 → 再分解……
实际就是 ABSD 六步在一个具体金融场景中的完整跑一遍。

五、ABSD 在面试中的用法：把“流程”讲清楚就是加分项

原文最后给了 3 道典型面试题，你可以直接用 ABSD 思路来组织答案。

Q1：新业务的架构设计，你一般怎么做？
- 用 ABSD 六步串起来讲：
  - 需求（含非功能）→ 功能分解 / 模块化 → 选风格 / 选模板 → 文档化 & 评审 → 实现 & 构建库复用 → 演进。
Q2：如何选择合适的架构风格和软件模板？
- 关键：强调需求驱动：
  - 先看功能需求 + 非功能需求 + 限制；
  - 根据数据流形态 / 并发特点 / 可用性要求，选风格；
  - 再在该风格下挑模板（开源框架 / 内部平台 / 现成网关等）。
Q3：创建订单 / 更新订单 / 校验用户账号这几个用例之间是什么关系？
- 这是考 UML 和抽象能力：
  - “创建订单”在内部调用“校验账号” → include 包含关系；
  - 类似题里要熟练用“包含 / 扩展 / 泛化”表达用例关系。

当你能用 ABSD 这种“流程化 + 方法论”的方式去回答，
面试官会感受到的不是“你死记了几条经验”，而是你有一整套可复用的做事套路。

小结：ABSD 值得你带回日常工作的三个动作

建一个“需求视角更完整”的需求库：
- 把功能、非功能、限制都写在一起，而不是只记“需求大纲”。
把每次系统设计都拆成“小鸡啄米”的多轮分解：
- 不要一上来画一个巨大终极图；
- 每轮解决一部分，把抽象不断逼近实现。
有意识地维护自己的“构建库 / 模板库”：
- 常用模块、常用架构骨架、常用接入网关，都沉淀下来；
- 下次新项目就不是从 0 起步，而是从“复用 + 剪裁”起步。

当你在团队中越来越多地用这种方式带项目，你其实已经在用 ABSD 的架构思路工作了。
再往前一步，就是把这些沉淀成团队级 / 组织级的方法论和资产，那时你已经非常接近“架构师”的位置。