hello-arch

架构相关变更必须遵循以下规范。

编码前

先画出当前→目标依赖关系和变更路径，再写代码。

SOLID 原则

• 单一职责：一个模块/类只做一件事，变更只有一个原因
• 开闭原则：扩展开放，修改关闭——新功能通过扩展实现
• 依赖倒置：高层不依赖低层，都依赖抽象（接口/协议）

边界与分层

• 清晰的模块边界，通过接口通信
• 依赖方向：外层 → 内层（UI → Service → Repository）
• 循环依赖 = 架构问题，必须解决
• 配置与代码分离，环境变量管理

代码组织

• 按功能分组（feature-based），非按类型分组
• 代码体积控制（同当前已加载 bootstrap 的编码原则）：文件/类预警 300 行、强制拆分 400 行，函数预警 40 行、强制拆分 60 行。例外：生成代码、大型测试夹具、迁移脚本、协议常量表
• 公共逻辑提取到 shared/，但避免过早抽象
• 三次重复才提取——两次相似不够

变更策略

• 评估变更的影响范围（blast radius）
• 大重构分步进行，每步可独立验证和回滚
• 保持向后兼容，除非明确要求破坏性变更

交付检查

• 无循环依赖
• 文件/类不超过 400 行，函数不超过 60 行（例外类型除外，非压缩代码）
• 依赖方向正确（外 → 内）
• 变更范围可控
• 技术选型符合当前已加载 bootstrap 的技术下限要求；若当前模式未加载质量下限章节，则至少满足技术选型原则且新项目无过时依赖