架构设计框架

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

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

架构设计方法论

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

方法论的类型

类型 代表 分解维度 适用场景
过程驱动 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. 建立领域资产（组件、模式、接口等）。

三层模型

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

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

领域实现

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

总结与对比

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

反模式与误区

核心观点

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

ABSD 的三大误区

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

DSSA 的三大误区

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

两者共有的结构性陷阱

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

关联内容（自动生成）