软件架构是系统的高层设计决策，包括组织结构、行为模式、核心组件及其交互关系。
“Architecture is the decisions that you wish you could get right early in a project.” — Ralph Johnson
| 维度 | 架构 | 设计 |
|---|
| 抽象层次 | 系统级 | 模块级 |
| 关注点 | 全局约束和决策 | 局部实现细节 |
| 变更成本 | 极高 | 较低 |
| 影响范围 | 整个系统 | 单个模块 |
| 决策者 | 架构师 | 开发者 |
| 要素 | 说明 |
|---|
| 组件 | 系统的构建块 |
| 连接器 | 组件间的交互机制 |
| 约束 | 组件和连接器的使用规则 |
| 配置 | 组件和连接器的组合方式 |
| 职责 | 说明 |
|---|
| 技术决策 | 选择技术栈和架构风格 |
| 质量保障 | 确保系统满足质量属性 |
| 风险管理 | 识别和缓解技术风险 |
| 沟通桥梁 | 连接业务和技术团队 |
| 技术指导 | 制定技术标准和规范 |
| 知识传承 | 培养团队技术能力 |
技术深度 ──── 对特定领域的深入理解
技术广度 ──── 跨领域的技术视野
业务理解 ──── 将业务需求转化为技术方案
沟通能力 ──── 与不同角色有效沟通
决策能力 ──── 在不确定性下做出决策
领导力 ──── 引导团队走向正确方向
# ADR-001: 选择微服务架构
## 状态
已接受
## 背景
单体应用已无法满足业务快速增长的需求，团队规模扩大后协作效率下降。
## 决策
采用微服务架构，按业务域拆分服务。
## 理由
1. 独立部署：各服务可独立发布
2. 技术异构：各服务可选择合适技术栈
3. 团队自治：每个团队负责自己的服务
4. 弹性伸缩：按需扩展高负载服务
## 后果
- 增加运维复杂度
- 需要服务发现和API网关
- 分布式事务处理更复杂
- 需要更完善的监控体系
| 原则 | 说明 |
|---|
| 延迟决策 | 在必须决策时再做决定 |
| 可逆性优先 | 优先选择可逆的决策 |
| 证据驱动 | 基于数据而非直觉 |
| 最简可行 | 选择最简单的可行方案 |
| 适度设计 | 满足当前需求，预留扩展空间 |
| 层级 | 视图 | 受众 | 关注点 |
|---|
| Level 1 | 系统上下文图 | 所有人 | 系统与外部的关系 |
| Level 2 | 容器图 | 开发者/架构师 | 系统内部的容器 |
| Level 3 | 组件图 | 开发者 | 容器内部的组件 |
| Level 4 | 代码图 | 开发者 | 组件内部的类 |
| 视图 | 说明 | 关注点 |
|---|
| 逻辑视图 | 功能分解 | 终端用户 |
| 进程视图 | 并发和同步 | 集成者 |
| 开发视图 | 代码组织 | 程序员 |
| 物理视图 | 部署拓扑 | 运维人员 |
| 反模式 | 症状 | 解决方案 |
|---|
| 大泥球 | 无清晰架构，代码纠缠 | 逐步重构，引入分层 |
| 过度工程 | 架构过于复杂 | YAGNI，简化设计 |
| 复制-粘贴架构 | 多个服务结构完全相同 | 提取共享库/平台 |
| 供应商锁定 | 过度依赖特定技术 | 抽象层、多供应商策略 |
| 架构黑洞 | 架构决策不落地 | ADR + 代码审查 |