架构设计框架
软件架构设计是连接业务愿景与技术实现的桥梁。一个合理的架构不仅要满足业务目标，更要具备足够的灵活性和演化能力，以应对未来的变化。
一、什么驱动着架构设计
架构设计并非单纯的技术活动，而是由多种力量共同驱动的系统性工程。
**业务需求**架构存在的首要目的，是支持业务目标的达成。业务流程、产品功能、用户体验等都将决定架构形态。
**非功能需求**包括性能、可靠性、安全性、可扩展性、可维护性、成本约束等。这些隐性需求往往是架构设计成败的关键。
**设计与实现限制**例如组织架构、团队能力、预算周期、既有技术栈、法律合规要求等。限制条件决定了架构设计的可行边界。
二、ABSD（基于架构的软件开发）
ABSD（Architecture-Based Software Development）是一种以架构为核心驱动的软件开发模式。它强调自顶向下的分解、架构风格选择、构件化实现与持续演化，通过架构模型来指导整个软件生命周期。
1. 功能分解
**自顶向下分解**：从系统整体目标出发，逐层细化功能模块。
**核心目标**：将需求转换为逻辑模块，实现**高内聚、低耦合**的系统结构。
**分解过程**：
- 分析系统用例或业务场景；
- 提取核心功能域；
- 明确模块边界与接口；
- 识别共性服务与独立职责。
2. 架构风格
选择合适的架构风格是架构设计的关键环节。常见风格包括：
- 分层架构（Layered Architecture）
- 微服务架构（Microservices Architecture）
- 事件驱动架构（EDA）
- 面向服务架构（SOA）
- 客户端-服务器（C/S）
- 管道与过滤器（Pipe & Filter）
架构风格体现的是系统**“整体形态”与“交互模式”**的选择，是从设计原则到系统结构的第一次映射。
3. 软件模板
软件模板用于描述系统中各个软件元素如何协作。它定义了：
- 各构件的职责；
- 它们如何通信；
- 在基础设施（存储、消息中间件、认证系统等）上的依赖关系。
模板的目标是建立一套可重用、可扩展的“软件装配蓝图”。
4. 递归与迭代
架构设计不是一次性活动，而是递归式的演进过程：
- 每一层次的设计结果，都会反馈到更高层次；
- 新需求、技术演变或业务变化都会触发架构再设计；
- 每次迭代都在验证和强化架构的适应性。
三、ABSD 实施流程
（1）架构需求阶段
- 从需求库中提取“**小而多**”的功能项；
- 将这些需求映射为概念类或组件；
- 绘制初步的类图和构件图；
- 对需求进行评审，确保其明确、独立、可验证。
目标：将需求具体化为可设计的构件单元。
（2）架构设计阶段
- 选择合适的架构模型与风格；
- 将需求阶段划分的构件映射到架构模型；
- 分析构件之间的依赖与交互；
- 明确系统的通信机制、部署拓扑；
- 输出可视化架构文档；
- 进行设计评审。
目标：建立可实现、可演化、可验证的架构蓝图。
（3）架构实现阶段
- 根据复审后的架构文档执行详细设计；
- 开发并组装构件；
- 进行集成测试与系统验证；
- 建立自动化构建、监控与部署机制；
- 为架构演化留出技术扩展点。
目标：让架构从设计模型转化为可运行系统。
（4）架构演化阶段
- 监控需求变化并进行分类（功能性、非功能性、外部限制等）；
- 制定架构演化计划；
- 确定需要调整的构件；
- 重组架构、执行回归测试；
- 组织技术评审与经验回溯。
目标：确保架构能持续支持业务变化和技术更新。
四、DSSA（特定领域的软件架构开发）
DSSA（Domain-Specific Software Architecture）是一种面向领域的架构开发方法，强调在特定业务领域内的知识沉淀与架构复用。与 ABSD 不同，它关注的是跨系统、跨项目的长期积累。
1. 领域分析
领域分析的目标是：
对业务领域知识进行抽象、拆解与结构化，以提炼可复用的模型和构件。
关键参与者：
- **领域专家**：掌握业务知识；
- **领域分析人员（业务架构师）**：负责业务结构建模；
- **领域设计人员（技术架构师）**：将业务模型转化为技术架构；
- **领域实现人员（开发者）**：开发并验证领域组件。
过程特点：
- 强调多角色协作；
- 通过持续迭代实现知识传承；
- 构建“老带新”的知识沉淀体系。
2. 领域设计
领域设计阶段将分析成果转化为领域架构模型。
关键任务：
- 定义领域范围与边界；
- 识别领域特定的核心元素与约束；
- 制定通用设计原则；
- 定义领域模型的整体架构；
- 建立领域资产（组件、模式、接口等）。
三层模型（概念验证框架）
| 层级 | 说明 |
|---|---|
| 领域开发环境 | 聚焦知识建模与概念验证，形成领域模型原型 |
| 应用开发环境 | 将领域模型转化为可用框架与组件库 |
| 应用执行环境 | 在真实系统中验证领域架构的可行性与性能 |
这种分层有助于快速验证设计理念与复用策略。
3. 领域实现
- 优先使用现有可复用构件；
- 新开发的构件应沉淀回领域元件库；
- 采用**螺旋式开发模型**进行持续演进与发布；
- 定期审查领域模型的有效性与扩展性。
目标：构建一个能够“越用越强”的领域架构生态系统。
五、总结与对比
| 维度 | ABSD | DSSA |
|---|---|---|
| 目标 | 从需求出发设计系统架构 | 从领域出发建立复用架构 |
| 关注点 | 单个系统生命周期 | 多系统间的领域复用 |
| 方法论 | 功能分解 + 架构风格 + 构件化 | 领域建模 + 元件库 + 迭代复用 |
| 输出物 | 架构模型、设计文档、构件集 | 领域模型、元件库、开发框架 |
| 适用场景 | 新系统开发 | 平台化、产品线开发 |
六、结语
架构设计框架并不是一种固定模式，而是一种思维方式。ABSD 帮助我们从需求走向系统；DSSA 帮助我们从系统走向复用。
两者结合，形成了现代软件工程中“架构驱动开发（Architecture-Driven Development）”的完整闭环：
从需求 → 架构 → 实现 → 复用 → 再演化。