核心用法
Layered (N-Tier) Architecture 是一种经典的分层架构范式，通过强制依赖方向与层级边界，将系统划分为 Presentation、Application/Service、Domain、Data Access 四个核心层次。每层仅能依赖紧邻的下层，严禁向上依赖或跨层调用。该技能提供从架构决策、依赖图维护到自动化规则检查的完整实施路径。
显著优点：
- 清晰的关注点分离：UI、业务逻辑、数据持久化各司其职，降低认知负担
- 团队熟悉度高：MVC、Repository 等模式广泛普及，上手门槛低
- 合规友好：满足审计与运维团队对代码可见性的要求
- 技术栈灵活：各层可独立演进，如前端 React、后端 Java/Python 混用
- 测试策略明确：单元测试聚焦 Domain，集成测试覆盖 Persistence
潜在缺点/局限性：
- 刚性过强导致延迟：严格分层可能产生大量“透传”代码，增加调用链长度
- 不适合独立扩展：单体部署无法针对热点组件单独扩缩容
- 层间泄漏风险：开发者易为求快绕过规则，导致架构腐化
- 与微服务冲突：若规划独立部署或多团队自治，需直接选用微服务而非分层单体
适合人群：
- 维护中等规模单体系统的团队
- 需通过代码审计、合规检查的企业（金融、ERP、政务）
- 架构腐化严重、需重构治理的遗留系统
- 多前端共享统一业务规则的 B2B 平台
常规风险：
- 性能瓶颈：多层调用叠加可能拖慢实时处理场景，建议对高频路径采用 Façade 模式优化
- 规则执行失效：若无自动化检查（ArchUnit/dep-cruise），分层约定易沦为纸面文档
- 过度设计：小规模 CRUD 应用引入四层架构反而增加复杂度