用途：当团队需要一个熟悉且边界清晰的结构来设计中大型系统，或合规与运维要求明确分离关注点（UI、领域逻辑、持久化）时，采用此分层（N-Tier）范式。它适用于部署产物仍为单体、但代码清晰度与分离度下降的场景。
主要能力与内容：
- 采用步骤：定义分层（常见为 Presentation → Application/Service → Domain → Data Access）；强制依赖方向，只允许向下依赖，禁止向上依赖或导入；将日志、认证、校验等横切关注点集中为中间件或策略；按层采用合适测试（领域层单元测试、服务层编排测试、持久化适配器集成测试）；用依赖图与自动化架构测试防止“抄近路”依赖。
- 关键交付物：记录各层职责、允许依赖与例外策略的 ADR；与项目文档同存的正式依赖图；自动化架构检查（如 ArchUnit、dep-cruise 或自定义脚本）以阻止违规合并。
- 技术指引：表示层可用 React/Vue/Angular 或 MVC 控制器；应用层为服务类、用例编排器；领域层为业务实体、领域服务与规则校验；数据访问层为 Repository、ORM 映射器、DAO。工具方面，Java 用 ArchUnit，JS/TS 用 ESLint 依赖规则，C# 用 NDepend，Python 可用自定义装饰器与导入分析。常见层栈为 3 层、4 层与 5 层。
- 风险与缓解：严格遵循易导致穿透代码与延迟，可用 Façade 模式提供更直接接口；对“漏层”违规应视为构建失败或代码评审严重问题。
- 组件词汇：dependency-validator（层向上导入时构建失败）、layer-enforcer（检查命名空间是否符合层规则）、architecture-compliance-checker（对比实现与文档层图）。
- 退出标准：ADR 记录层栈与例外策略；依赖图与 ADR 一致并提交到文档；CI 中接入自动化架构检查并在向上依赖时构建失败；横切关注点只实现一次。
适用场景：企业 ERP、银行交易、传统电商等需要严格分离关注点的系统。
限制：不适用于需要组件独立伸缩、多团队独立部署、复杂业务频繁跨层通信、已计划或已采用微服务、以及实时处理要求使分层通信过慢的场景。具体收费、价格与平台支持情况暂未提供。