核心用法
Layered (N-Tier) Architecture 是一种经典的软件架构范式，通过将系统划分为水平层级（如 Presentation → Application → Domain → Data Access），强制实施单向依赖原则（上层仅可依赖紧邻下层），从而实现关注点分离。该 Skill 提供从范式选择、层定义、依赖 enforcement 到自动化架构测试的完整采用路径。
显著优点
1. 认知门槛低：分层模式是行业最广泛理解的架构范式，新成员 onboarding 成本低
2. 关注点隔离清晰：UI、业务逻辑、持久化各司其职，便于并行开发与独立演进
3. 测试策略分层：各层可采用最适合的测试类型（单元/集成/契约测试）
4. 合规友好：满足审计对数据访问层与业务逻辑分离的硬性要求
5. 工具生态成熟：ArchUnit、NDepend、ESLint 等跨语言工具链完备
潜在缺点与局限性
- 弹性扩展受限：单体部署制约组件独立扩缩容
- 跨层协作开销：频繁跨层调用导致 "pass-through" 代码膨胀与延迟累积
- 团队耦合度高：无法支持多团队独立部署节奏
- 实时性瓶颈：分层通信模型不适合低延迟实时场景
- 僵化风险：过度严格的分层可能阻碍必要的技术债务重构
适合人群
- 中小型团队维护的中等规模业务系统（<50 万行代码）
- 合规要求严格的金融、ERP、政务领域
- 单体部署但代码组织混乱、亟需重构的遗留系统
- 微服务过渡期的临时架构方案
常规风险
1. 层泄漏（Leaky Layers）：开发者绕过分层规则走捷径，需将架构违规视为构建失败
2. 性能劣化：跨层边界的数据转换与调用链过长，建议对热点路径采用 Façade 模式优化
3. 过度工程化：简单 CRUD 系统强行套用多层栈反而增加复杂度
4. 依赖方向反转：需借助 ArchUnit 等工具在 CI 中强制执行单向依赖约束
该 Skill 附带完整的技术选型指南（含 Java/TypeScript/C#/Python 的 enforcement 工具）及真实案例（SAP ERP、银行核心系统、电商平台），是单体系统架构治理的实用参考。