夜雨聆风
基于架构的软件开发方法
ABSD
Architecture-Based Software Development
看名字就是知道了，这是一个以架构为驱动的方法
—— 在开始软件开发之前，先把整个架构设计好
更详细地说，由 商业、质量和功能需求 的组合来共同驱动软件架构的设计
为什么呢？🤔
这就不得不提到 结构化设计 SD了
SD 是一种面向数据流的开发方法
—— 通过自上而下进行功能分解，从而设计出模块和他们之间的关系
—— 只确定了做什么，怎么做
但是功能的分解实现只是 软件开发的 一部分
更重要的还有 质量属性、商业 等要求
—— 就是关注 性能，安全，可维护，成本等多种非功能需求
比如说你实现一个商城，是能完成功能了，但是又慢又容易崩溃，或者说 一个小商城采用过度的高并发设计，在技术上付出太多money，导致收不回本
这便是 基于架构 要解决的问题
—— 要能做得到，还能做得好
那这个 ABSD 是怎么做的呢
三个核心
六个步骤
三个核心
三个核心，就是
功能分解
选择架构风格
选择软件模板
① 功能分解，这个和SD是一样的，通过 自上而下的方法， 把庞大复杂的系统拆解为多个职责单一、相对独立的小模块
比如一个商城，先将其在概念上分解为 【订单子系统】 【支付子系统】 【用户子系统】，把一整块错综复杂的业务逻辑 梳理成分类有序的模块
附上一张 SD 的 模块结构图
② 选择架构风格，架构风格 来确保系统能满足性能、安全性等非功能质量需求和商业需求
因为同一种功能，可以有多种架构风格选择，而只有多方的考虑，才能确定具体的风格
比如说如果强调安全性，就会选择 层次结构风格，分成4层或者N层，重要的资产放在内层保护
但是分层架构为了实现解耦，数据会层层传递，这就会影响性能
但是如果同时强调性能，就可能会允许越级调用的开放型分层模式
也就是从严格的层层传递，A→B→C→D
变成了特殊请求可以越级传递，A→C
再比如说 实现一个企业管理系统
只为了实现功能，可以选择 C/S风格（客户端/服务器），功能性更丰富
但是 客户要求 便利性，可能就选择 B/S风格（浏览器/服务器）
然后 客户又要求安全性，而C/S风格在 安全性不足，转而重新选择 B/S 架构
③ 选择软件模板，就是利用已有的成熟的软件结构作为抄袭借鉴
风格只是一个大体的设计方向， 而市面上不同风格早就有了成熟的软件设计，所以可以直接借鉴，直接免去了整体设计这一步了
比如说你的系统想开发一个插件功能，支持动态热拔插的形式扩展功能
你就可以借鉴编辑器的插件架构，比如说 Eclipse IDE ，Vscode
保持微小的核心，定义插件的规范、维护一个插件注册表，以及负责插件的查找、装入和注销
扩展点，核心系统对外开放许多插槽，接入插件的地方
动态热拔插，基于OSGi动态模块化规范，可以在不重启系统的情况下实现插件的安装、更新和卸载
不用在意怎么实现了，以后直接就
“AI 帮我参考 Vscode 的插件架构，开发一套插件功能”
所以了解就好
六个步骤
这个是真正要进入开发了，实打实的执行步骤
架构需求
架构设计
架构文档化
架构复审
架构实现
架构演化
整个过程是一个螺旋循环迭代的过程，不是一蹴而就的
而且每个步骤又细分了很多步骤，是真正的有实质性指导意义的开发方法，不整虚的
就是这玩意用词确实晦涩难懂，但是其实也就需求开发那点东西
❶架构需求
具体分为五个步骤
需求获取
生成 类图
对类图分组
类打包构件
需求评审
这一看就抽象得不行，不用怕！
需求获取，关注的不仅是功能，更重要的是 非功能需求，性能，可靠性，安全性等等
比如说做一个商城的抢购功能，看起来的流程和 商品购买 没有什么两样
但是抢购开始的那一瞬间，可能会有几百万用户同时疯狂抢购，那么
—— 这种海量并发系统不崩溃，商品不会超卖 就是 架构的需求
而为了满足这些目标，架构师才会决定在系统里引入集群、分布式缓存和消息队列 等设计
高并发的架构可以参考这里 高并发架构
标识构件分为三步，其实核心就是整理需求
生成类图，提取出最基础的业务实体代码模型，比如说订单 、订单明细，商品，用户 ，商品评价等等
对类分组，把上面的这些类，按照关联性分组，比如说，“订单”和“订单明细”就是 一个组，商品 和 商品评价一个组
类打包成构件，把刚才分好组的，封装成具有标准接口的实体。比如说 ，把 订单+订单明细 直接打包成一个大粒度的 订单管理构件
需求评审，就是看你的构件组合是否合理，是否有遗漏，并且评审非功能的需求是否合理
“10 万并发搞这么多？我们有这么热门吗”
“1s 就响应？3s 行不行”
循环，评审没通过，回到第一步，重新获取需求，标识构件...
❷架构设计
具体也是五步
提出架构模型
映射构件
分析构件相互作用
产生架构
设计评审
提出架构模型，就是选择一个合适的架构风格
映射构件，把 架构需求中得到的 构件，对应地放到架构风格模型中
因为 架构的 3C模型分为了 构件，连接件，约束嘛
也就是架构 定义了系统内构件的样子，构件的协作
还不了解什么是架构 → 架构
所以这里把前面的构件 试图一一对应到 架构风格的 构件中
比如说 上一步采用了 微服务架构，那么 订单构件，支付构件，库存构件 就作为独立的构件
分析构件相互作用，规定这些构件之间如何通信、数据如何流转
比如说 订单微服务 不能直接调用 库存微服务，而是必须通过一个消息队列（连接件）进行异步通知
产生架构，通过上述内容的确定，就可以画出完整的架构图了
系统有什么元素，元素之间怎么通信
通常就是用UML 绘制 4+1 视图，因为架构不是给一个人看的，这里的是实现视图
设计评审，还要评审，评审你这个架构 是否 顶得住那些需求
“一个消息队列就想抗住10w并发？”
于是你就打回重新设计，加入了 Redis 缓存层
❸架构文档化
前面都是一些草图，比较零散和抽象
现在就要落地成规范正式的说明文档了
具体就是两个产物
架构规格说明
测试架构需求的质量设计说明书
架构规格说明
—— 说明你的架构决策 和 设计原因，比如为了高并发才选择的消息队列通信，然后通过 4+1 视图 多视角 描述架构
—— 明确构件的职责，明确 订单服务 和 库存服务 这两个构件的职责和具体的交互接口
测试架构需求的质量设计说明书
—— 就是根据前面定的质量标准，制定要怎么去测试
—— 比如 验证性能目标，要在什么环境下，要如何触发 每秒 10 万次并发
这份设计文档的要求就是 要足够通俗易懂
—— 要所有人都能看懂，即使没有参与过程，拿到文档也能轻松看懂，知道自己接下来的代码该怎么写
❹架构复审
这一步的架构复审 和 第二步架构设计的技术评审 是不一样的
第二步的技术评审，只是一个草图大概
而 架构复审，是针对上一步得到的 正式文档
其实就是 更全面的架构评估，找出 敏感点、权衡点、风险点
通过各种专业的评审方法，比如 SAAM 、ATAM、CBAM 等
内容太多，可以看这里 架构评估
简单说
你的这个架构不能只兼顾某个 质量属性
比如说为了安全，你就把加密级别调到最高，导致解密严重影响性能
那这个 安全属性，就是 权衡点
比如说当前的架构设计性价比是否高，比如一个小商城，确定要使用 纯高并发设计吗？ 这就是 成本的考量
当前的技术团队，没有实现这个架构的经验，这便是 风险点
❺架构实现
万事俱备，只欠东风了
要开始投入真正的开发了，步骤看起来晦涩，其实就是开发
分析和设计
构件的实现
构件的组装
系统测试
分析和设计，就是针对架构，开始分工了，各自开展内部的详细设计
构件的实现，分为三种，一种直接用第三方，一种是开发，一种是从老系统抽离，比如说
消息队列构件，直接用第三方的 Kafka
订单构件，需要自己实现
支付构件，在其他系统中有实现，可以试图抽离成公共构件
构件的组装，其实就是构件之间的联调呗
把写好的构件实体相互连接拼装起来，完成整个软件系统的合成
系统测试，我测！
单个构件独立的功能测试
全局的功能测试
质量属性场景的测试
循环开始，测试：“用例不通过，打回重做”
❻架构演化
演化，其实就是正常迭代了
步骤依旧抽象，分为
需求变化分类
架构演化计划
架构变动
更新构件相互作用
构件组装和测试
技术评审
其实就是架构实现那一part的变种罢了
需求变化分类，分析新需求，进行分类，确认是修改已有构件还是创建新构件
架构演化计划，其实就是制定任务并分配，比如说确定是修改 订单构件了，那么就
“XXX 你去开发”
“定在下周联调，下下周发布！”
架构变动，其实就是对 构件的增删改了
更新构件相互作用，构件的增删改，肯定要重新更新他们之间的交互逻辑。
比如说 订单构件 新增的逻辑，在购买管控物品前，先去检查该人是不是实名认证
那么在 调用订单构件之前，应该先调用 认证构件
其实我觉得这部分应该是在架构变动中的
构件组装和测试，写完就重新联调，进行整体的测试
看看改完之后，会不会影响之前 10w并发的目标
技术评审，评审架构是否满足了功能需求 和 非功能需求
比如说加了 实名认证，导致订单响应慢了1s
“这怎么回事啊！这是硬性指标啊，加个认证就1s，那加个优惠券是不是又要1s？最后要10s 生成一个订单？”
看完这6大步骤
估计头都要晕古7了
但是只要记住 ABSD 是架构驱动为主
—— 由 商业、质量和功能需求 的组合来共同驱动
因为一个软件不只有功能，所以架构的设计才显得尤为重要
当然了 ABSD 的详细执行步骤看着确实很繁琐
但是实际执行的时候都是动态的，因为是教科书，所以尽量是以详细为主
简化来说无非就4点
确定架构目标
确定架构风格 和 套用成熟模板
架构评估是否满足目标，多种属性等
架构开发
而 ABSD 也不是所有场景都适用，一看就是大场面选手，不然那这些步骤折腾来折腾去，我都开发完了
所以小需求，其实 SD 就已经足够了
（完）