架构设计框架

架构设计框架是用于系统化指导架构决策的思维模型与工具集合,通过结构化的方法降低设计复杂度、支撑决策过程。

背景:所有架构问题都存在局部最优与全局最优的根本矛盾——拆分带来独立性但增加复杂度,复用减少重复但引入耦合,集中管理保证一致性但牺牲灵活性。架构师的核心职责是在这个矛盾中做出可持续的权衡。

架构设计方法论

架构设计方法论是将复杂系统进行结构化分解的思维方式,核心是分而治之——通过分解降低认知负担,通过定义分解后的交互方式管理复杂度。

方法论的类型

类型代表分解维度适用场景
过程驱动ABSD活动 → 构件需求明确的大型系统
数据驱动DSSD数据 → 实体数据密集型系统
视图驱动4+1视图视图 → 关注点多利益相关方沟通
框架驱动TOGAF层次 → 工件企业级架构治理

架构认知层次

运用方法论时,架构师需要三个认知层次:

  1. **分解**:将系统拆分为可理解的模块
  2. **交互**:定义模块间的协作方式
  3. **权衡**:在分解的代价与收益间做出决策

驱动因素

选择和应用方法论前,需明确架构设计的驱动因素,驱动因素决定分解的维度与目标:

ABSD

ABSD是一种以架构为核心驱动的软件开发模式。它强调自顶向下的分解、架构风格选择、构件化实现与持续演化,通过架构模型来指导整个软件生命周期。

本质上,ABSD 适合"问题域清晰、变化可预期"的场景;不适合"需求不确定、需要快速验证假设"的场景。

功能分解

功能分解是ABSD将系统级目标转化为可设计、可分工的模块单元的唯一途径

架构风格

选择合适的架构风格是架构设计的关键环节。架构风格决定了系统的整体形态与交互模式,是所有后续设计决策的基础——风格选错,代价极高常见风格包括:

架构风格体现的是系统**”整体形态””交互模式”**的选择,是从设计原则到系统结构的第一次映射。

软件模板

软件模板是构件协作的契约定义,确保分解后的模块能正确集成。用于描述系统中各个软件元素如何协作。它定义了:

模板的目标是建立一套可重用、可扩展的”软件装配蓝图”。

递归与迭代

架构设计不是一次性活动,而是递归式的演进过程

ABSD 实施流程

架构需求阶段

  1. 从需求库中提取”**小而多**”的功能项;
  2. 将这些需求映射为概念类或组件;
  3. 绘制初步的类图和构件图;
  4. 对需求进行评审,确保其明确、独立、可验证。

目标:将需求具体化为可设计的构件单元。

架构设计阶段

  1. 选择合适的架构模型与风格;
  2. 将需求阶段划分的构件映射到架构模型;
  3. 分析构件之间的依赖与交互;
  4. 明确系统的通信机制、部署拓扑;
  5. 输出可视化架构文档;
  6. 进行设计评审。

目标:建立可实现、可演化、可验证的架构蓝图。

架构实现阶段

  1. 根据复审后的架构文档执行详细设计;
  2. 开发并组装构件;
  3. 进行集成测试与系统验证;
  4. 建立自动化构建、监控与部署机制;
  5. 为架构演化留出技术扩展点。

目标:让架构从设计模型转化为可运行系统。

架构演化阶段

  1. 监控需求变化并进行分类(功能性、非功能性、外部限制等);
  2. 制定架构演化计划;
  3. 确定需要调整的构件;
  4. 重组架构、执行回归测试;
  5. 组织技术评审与经验回溯。

目标:确保架构能持续支持业务变化和技术更新。

DSSA

DSSA是一种面向领域的架构开发方法,强调在特定业务领域内的知识沉淀与架构复用。与 ABSD 不同,它关注的是跨系统、跨项目的长期积累。

领域分析

领域分析的目标是:

对业务领域知识进行抽象、拆解与结构化,以提炼可复用的模型和构件。

关键参与者:

过程特点:

领域设计

领域设计阶段将分析成果转化为领域架构模型

关键任务:

  1. 定义领域范围与边界;
  2. 识别领域特定的核心元素与约束;
  3. 制定通用设计原则;
  4. 定义领域模型的整体架构;
  5. 建立领域资产(组件、模式、接口等)。

三层模型

层级说明
领域开发环境聚焦知识建模与概念验证,形成领域模型原型
应用开发环境将领域模型转化为可用框架与组件库
应用执行环境在真实系统中验证领域架构的可行性与性能

这种分层有助于快速验证设计理念与复用策略。

领域实现

目标:构建一个能够”越用越强”的领域架构生态系统。

总结与对比

维度ABSDDSSA
目标从需求出发设计系统架构从领域出发建立复用架构
关注点单个系统生命周期多系统间的领域复用
方法论功能分解 + 架构风格 + 构件化领域建模 + 元件库 + 迭代复用
输出物架构模型、设计文档、构件集领域模型、元件库、开发框架
适用场景新系统开发平台化、产品线开发

反模式与误区

核心观点

方法论本身不是问题,对方法论的误用才是问题。ABSD 与 DSSA 各自都隐含着若不规避则必然失效的认知陷阱。

ABSD 的三大误区

误区描述后果
风格漂移功能分解完成后,架构风格选择变成随意搭配系统整体形态失去一致性
模板缺位只做分解,不定义构件之间的协作契约集成阶段出现大量接口冲突
迭代空转声称"迭代",但每次迭代不反馈到更高层次架构设计与实际实现持续脱节

DSSA 的三大误区

误区描述后果
领域圣杯化把领域模型当作终极真理,抗拒业务变化模型僵化,反而成为变更阻力
元件库沉没建立元件库但不建立贡献机制领域资产逐渐与业务脱节,最终废弃
三层空转三层模型存在,但每层没有真正的职责边界形式上的分层,实质上的耦合

两者共有的结构性陷阱

陷阱在 ABSD 中的表现在 DSSA 中的表现
局部最优强迫症过度追求模块内的高内聚,忽视模块间协作成本过度追求领域模型的纯粹性,忽视跨领域集成需求
设计一次性交付把架构设计当作需求阶段的终点,而非起点把领域资产建立当作项目结束的工作,而非持续投入

关联内容(自动生成)