属性驱动设计

即 ADD (Attribute Driven Design)ADD~(Attribute~ Driven~ Design) ，通过系统化方法创建高质量、可预测和可重用的软件架构

ADD 3.0

更现代化的属性驱动设计：

  • 迭代设计方法：支持在项目增量（如Sprint）中进行迭代，通过微迭代实现结构化设计
  • 稳定且行业验证：具有普遍适用性
  • 适应性与一致性：适用于现代技术如DevOps和基于云的架构

ADD的关键步骤如下：

步骤一：检查输入

在设计之前，需要确保设计过程中的输入是可用且正确的，这里的检查包含多个维度的可用，比如：

  • 设计目的
  • 主要功能
  • 质量属性场景
  • 架构约束
  • 关注点
  • 现有架构

主要功能和质量属性场景需要被优先排序，理想情况下由项目利益相关者完成；

确保正确获取驱动因素及其优先级，避免“垃圾进，垃圾出”：

  • 检查原始需求获取过程中是否遗漏了重要利益相关者
  • 检查优先级确定之后业务条件是否发生了变化

示例：

步骤二：通过选择驱动因素建立迭代目标

这一步设计问题被分解成了几个子问题，迭代从决定解决哪个子问题开始。

一个设计周期通常以一系列设计迭代的形式进行，其中每次迭代都专注于实现一个特定的目标；需要设定一个适度的迭代目标：

  • 可能是解决单个重要驱动因素
  • 可能是为了满足一组相似的驱动因素而做出决策

示例：

ADD：迭代1，迭代目标和输入：

  • 迭代目标：创建总体系统结构
  • 需要考虑的输入：所有

步骤三：选择系统中的一个或多个元素进行细化

针对子问题做出三种决策类型中的一种之：选择需要分解的部分

细分意味着：

  • 分解为更细粒度（自上而下）
  • 组合元素为粗粒度（自下而上）
  • 改进先前已识别元素

对于Greenfield开发，可以从以下步骤开始：

  1. 建立系统上下文
  2. 选择唯一可用元素（即系统本身）进行分解细化

对于现有系统或Greenfield系统中的后续设计迭代：

  • 完善先前迭代已识别的元素
  • 深入理解系统元素

有时候，step2和step3可以颠倒

步骤四：选择一个或多个满足所选驱动的设计概念

针对子问题做出三种决策类型中的一种之：识别和选择支持分解的现有方案

4.1 识别设计概念

可以参考各种架构备选方案，比如移动应用程序、服务应用、Web应用程序等；也可以考虑分布式部署模式替代方案

4.2 设计概念的选择

基本选择方法：创建一个优缺点表，列出每种替代设计方案的优劣，以支持基于驱动因素的选择。示例：

深入分析方法：

  • CBAM：使用效用-响应曲线、成本效益分析和ROI来选择策略的定量方法：

  • SWOT：优点、缺点、机会和威胁

基于原型的选择：

  • 当分析失败，创建一次性原型

  • 与分析相比，创建原型成本更高

    某些场景需要原型，比如涉及新兴技术或不确定的技术集成

  • 在决定是否创建原型时，应该考虑：

    • 是否涉及新技术
    • 公司是否首次使用该技术
    • 是否存在某些驱动因素，选定技术实现时存在风险
    • 是否缺乏可信的信息确保技术能满足需求
    • 是否需要测试
    • 所选技术是否能与项目中其他技术集成

设计概念的选择示例：

  • 选择了两个参考架构：

  • 三层分布式部署

步骤五：实例化架构元素，分配职责并定义接口

针对子问题做出三种决策类型中的一种之：从现有解决方案中创建元素，并建立它们之间的职责和接口

示例：

步骤六：绘制视图并记录设计决策

这一步可以与步骤五同时进行，生成的不是完整文档，而是草图。

在实例化设计概念时，创建的草图是架构的初步文档：

  • 可以记录下来稍后完善
  • 符号保持一致
  • 养成记录“分配给元素的责任和做出的决策”的习惯

这可以减轻事后记忆负担

步骤七：对当前设计进行性能分析，并审查迭代目标与设计目标的达成情况

在此阶段做出的决策将结合整体设计进程的进展进行分析，以决定是否需要更多迭代。

示例：设计看板

注

更详细的完整ADD迭代示例见课件 Lectue 01 - Attributes Driven Design

设计过程终止标准

满足以下条件之一即可终止多次迭代：

  • 所有驱动设计决策都已做出架构需求
  • 最重要的技术风险得到缓解
  • 分配给架构设计的时间被耗尽（尽管这并不理想）

否则只要有必要，就继续进行迭代

Design concept selection roadmap for greenfield systems

将ADD应用于不同系统上下文

根据系统类型调整设计方法

有如下几种软件系统设计情况：

  • 为一个成熟系统（运行良好）设计一个Greenfield系统
  • 为一个新兴领域（基础设施 / 知识库尚未完全）设计一个Greenfield系统
  • 运用设计修改现有系统（其实也是成熟领域 / 系统）

在成熟领域中设计Greenfield系统

为桌面、移动、web企业应用和微服务等知名领域中的“从零开始”系统进行设计

迭代过程：

  1. 初始迭代目标：建立整体系统结构，选择参考架构、模式和框架优先考虑非功能性约束和质量属性
  2. 下一次迭代目标：识别主要功能结构，将用例分配给元素，分解参考架构元素
  3. 后续迭代：优化剩余驱动程序的架构，采用适当的策略、设计模式、组件和最佳实践（模块化、低耦合）等

Roadmap优势：指导初始设计，辅助早期估算。使用已知组件且遵循定义好的Roadmap，可以降低风险并从一开始就支持质量目标

在新兴领域设计Greenfield系统

  1. 从无参考架构开始：没有现有模型或者可重用的组件，完全从零开始
  2. 使用原型和通用(general)的概念：使用设计模式、质量属性来指导原型设计
  3. 面对新挑战：关注性能、可扩展性、安全性，且新领域的迭代目标更灵活

改进现有系统

  1. 多个重新设计的目标：老系统的架构设计通常被维护、重构或解决质量问题驱动
  2. 需要理解现有架构：在进行分解或做迭代计划前，关键是要识别系统元素及它们之间的交互
  3. 评估后再进行设计迭代：一旦理解了现有架构，ADD步骤就会把目标逐步放在新驱动器上

替换遗留应用程序

  1. 遗留技术债：旧系统可能依赖过时的技术或难以管理的技术债务
  2. 使用绞杀榕模式：引入代理将调用路由到遗留系统，同时逐步替换组件
  3. 迭代地替换：每个ADD迭代中的设计目标是针对特定服务或组件的

(•‿•)