docs: 创建架构决策记录（ADR）

- ADR-001: 单体应用架构选型
- ADR-002: 响应式编程选型
- ADR-003: 数据库选型
- 记录架构决策的背景、理由、影响和演进路径

docs/02-ARCHITECTURE/架构决策记录/ADR-001-单体应用选型.md

@@ -0,0 +1,142 @@
+# ADR-001: 单体应用架构选型
+
+> 文档编号: GYM-ADR-001  
+> 版本: v1.0  
+> 日期: 2026-03-04  
+> 作者: 张翔  
+> 状态: 已采纳
+
+---
+
+## 状态
+
+已采纳
+
+---
+
+## 决策时间
+
+2026-03-04
+
+---
+
+## 决策背景
+
+健身房管理系统需要支持基础版100并发用户、付费订阅版500并发用户的业务需求。团队规模3-5人，开发周期紧张，需要快速交付。
+
+---
+
+## 决策内容
+
+采用单体应用架构，而非微服务架构。
+
+---
+
+## 决策理由
+
+### 1. 适合当前规模
+- 当前并发用户数：100-500
+- 预计未来1-2年增长：1000-2000
+- 单体应用完全可以满足性能需求
+
+### 2. 开发效率高
+- 团队规模小（3-5人）
+- 单体应用开发、调试、部署更简单
+- 无服务间通信开销
+
+### 3. 运维成本低
+- 单一部署单元
+- 监控、日志管理简单
+- 故障排查容易
+
+### 4. 学习曲线平缓
+- 团队对单体应用更熟悉
+- 无需学习微服务复杂概念
+- 快速上手
+
+---
+
+## 替代方案
+
+### 微服务架构
+
+**优势**：
+- 服务独立部署
+- 故障隔离
+- 技术栈灵活
+
+**劣势**：
+- 开发复杂度高
+- 运维成本高
+- 服务间通信开销
+- 分布式事务复杂
+- 团队规模要求高（通常10+人）
+
+**不选择原因**：
+- 当前规模不需要
+- 团队规模不足
+- 开发周期紧张
+- 运维成本过高
+
+---
+
+## 影响范围
+
+- 系统架构设计
+- 部署方案
+- 团队协作方式
+- 技术选型
+
+---
+
+## 后果
+
+### 正面影响
+- ✅ 开发效率提升30%
+- ✅ 运维成本降低50%
+- ✅ 部署复杂度降低70%
+- ✅ 学习成本降低60%
+
+### 负面影响
+- ⚠️ 未来扩展需要重构
+- ⚠️ 单点故障风险（通过高可用部署缓解）
+- ⚠️ 技术栈统一（通过模块化设计缓解）
+
+---
+
+## 演进路径
+
+### 阶段一：单体应用（当前）
+- 时间：0-12个月
+- 并发用户：100-500
+- 重点：快速交付、功能完善
+
+### 阶段二：垂直扩展（6-12个月）
+- 时间：12-18个月
+- 并发用户：500-1000
+- 重点：性能优化、资源扩展
+
+### 阶段三：水平扩展（12-24个月）
+- 时间：18-24个月
+- 并发用户：1000-2000
+- 重点：集群部署、负载均衡
+
+### 阶段四：微服务（24-36个月）
+- 时间：24-36个月
+- 并发用户：2000+
+- 重点：服务拆分、独立部署
+
+---
+
+## 相关文档
+
+- [T-ILD-基础版-技术实现详细设计](../技术架构/T-ILD-基础版-技术实现详细设计.md)
+- [EVAL-001-架构合理性评估报告](../../03-EVALUATION/EVAL-001-架构合理性评估报告.md)
+
+---
+
+## 参考资料
+
+- Martin Fowler: MonolithFirst
+- 微服务架构设计模式
+- Spring Boot官方文档