arch-layered

一句话概述

将系统划分为水平层（通常为 Presentation → Business → Persistence → Database）。依赖严格向下流动：上层依赖下层，反之则不行。

何时使用此技能

• 具有清晰 UI／业务逻辑／数据分离的简单单体应用。
• 团队的首个服务端架构——分层架构是最容易理解的模型。
• 主要变化方向是“更换 UI”或“更换数据库”的系统（在合理范围内）。
• 受监管要求、团队规模或部署方式等约束，不适合采用微服务或事件驱动架构时。

何时不使用此技能

• 领域模型足够丰富，以至于业务层成为瓶颈，且应由它驱动其他所有层——请考虑 arch-hexagonal（它反转依赖方向，让领域处于中心）。
• 系统确实需要按业务能力独立扩展、部署或管理数据所有权——请参见 arch-microservices。
• 主要通信模式是异步且以事件为核心——请参见 arch-event-driven。

核心内容

典型的四层（也有其他变体）：

• Presentation — UI、API 控制器、命令行处理器。
• Business — 领域逻辑、用例、服务。
• Persistence — 存储库、ORM、数据访问。
• Database — 物理存储。

依赖规则：每一层都可以调用紧邻其下的层。有些团队允许跳过某一层（开放层），有些团队则禁止（封闭层）。应明确并记录约定。

开放层与封闭层。 封闭层要求每次调用都经过下一层——清晰，但冗长。开放层允许在某一层没有带来价值时绕过它（例如，在两个实际存在的层之间有一个很薄的“共享工具”层）。选择一种约定，不要混用。

为什么它是默认选择。 分层架构易于讲解、易于帮助新成员上手，也易于为 CRUD 类型的系统进行推理。除非有明确理由选择其他架构，否则它是合适的起点。

它何时会失效。 当业务层开始依赖持久化层的类型时（例如，领域实体是 JPA @Entity），抽象就反转了——数据库的尾巴开始摇动领域这只狗。这时就该考虑 arch-hexagonal 了。

决策启发

• 任何新单体应用都从分层架构开始。这是稳妥、朴素的选择，而这正是它的优点。
• 默认采用封闭层；只有在绕过某一层确实更清晰时，才将其设为“开放层”。
• 业务层不得导入 Presentation 层的内容。在 CI 中检测违规情况（参见 arch-fitness-functions）。
• 如果业务层总是需要基础设施类型（数据库连接、HTTP 客户端），说明架构可能需要反转——请考虑六边形架构。

反模式

• 黑洞反模式。 某一层存在的唯一作用，就是将调用原样传递给下一层，没有任何转换。这通常表明：（1）该层不该存在，或（2）该层应该开放。过度设计的“服务”层中很常见。
• 泄漏的层。 下层类型（JPA 实体、HTTP DTO）出现在上层中。这会让上层与下层的实现耦合。
• 双向依赖。 下层调用上层，通常通过回调或循环导入实现。这会破坏分层结构。
• 只有名称、没有架构的分层架构。 仅仅因为文件夹名为 presentation/、business/、persistence/，就称其为“分层架构”，却没有强制依赖方向。这只是名称上的把戏。

另请参阅

• arch-hexagonal — 当领域应处于中心，而非某一层中时使用。
• arch-fitness-functions — 在 CI 中强制执行层边界。
• ddd-anti-patterns — 贫血领域模型表明业务逻辑泄漏到了 Presentation／Persistence 层。

参考资料

• Richards 和 Ford，《Fundamentals of Software Architecture》，第 10 章（分层架构风格）。
• Buschmann 等人，《Pattern-Oriented Software Architecture, Vol. 1》——分层模式的原始参考资料。