architecture-paradigm-layered

分层（N 层）架构范式

何时采用此范式

• 当团队需要清晰的架构边界，以及适用于中等规模系统的熟悉结构时。
• 当合规或运维团队要求明确划分职责（例如，UI 与领域逻辑、持久化之间的分离）时。
• 当部署产物仍是单体，但代码的清晰度和分离程度正在下降时。

何时不应采用此范式

• 当高可扩展性要求组件能够独立扩展时
• 当多个团队需要独立的部署周期时
• 当复杂的业务逻辑需要频繁进行跨层通信时
• 当已经规划或部署了微服务架构时
• 当实时处理要求使分层通信速度过慢时

采用步骤

1. 定义各层：建立一套明确的分层结构。常见的层级包括：Presentation → Application/Service → Domain → Data Access。
2. 规范依赖方向：某一层中的代码只能依赖其正下方的层。禁止任何“向上”的依赖或导入。
3. 集中处理横切关注点：将日志记录、身份验证和校验等关注点实现为集中式中间件或策略，而不是在每一层重复实现这些逻辑。
4. 针对各层采用适当的测试方式：采用适合各层的测试策略，例如对领域层进行单元测试、对服务层的编排逻辑进行测试，以及对持久化适配器进行集成测试。
5. 记录并规范交互方式：维护最新的依赖关系图，并使用自动化架构测试，防止开发者创建违反分层规则的“捷径”依赖。

关键交付物

• 一份架构决策记录（ADR），记录每一层的职责、层间允许的依赖关系，以及任何例外情况的处理策略。
• 一份与项目文档一同保存的正式依赖关系图。
• 自动化架构检查（例如使用 ArchUnit、dep-cruise 或自定义脚本），以防止违规规则的代码被合并。

技术指南

分层实现模式：

• Presentation 层：React/Vue/Angular（前端）、MVC Controllers（后端）
• Application 层：Service 类、应用服务、用例编排器
• Domain 层：业务实体、领域服务、业务规则校验
• Data Access 层：Repository 模式、ORM 映射器、数据访问对象（DAO）

架构规范工具：

• Java：使用 ArchUnit 测试依赖规则
• JavaScript/TypeScript：使用带依赖跟踪功能的 ESLint 规则
• C#：使用 NDepend 进行架构分析
• Python：自定义装饰器和导入分析工具

常见分层结构：

• 3 层：Presentation → Business Logic → Data Access
• 4 层：Presentation → Application → Domain → Infrastructure
• 5 层：UI → Controller → Service → Domain → Persistence

真实案例

企业 ERP 系统：SAP 和 Oracle ERP 使用分层架构，将用户界面与业务逻辑、数据库操作分离，使不同的前端应用能够共享相同的业务规则。

银行应用：金融机构采用分层架构，严格分离面向客户的界面、交易处理和安全的数据存储，以满足合规要求。

电子商务平台：传统电商网站使用分层架构，将产品目录、购物车逻辑、订单处理和支付处理划分为不同的层。

风险与缓解措施

• 过度僵化和延迟：
  • 缓解措施：对于跨越多个层的功能，严格遵循规则可能会导致过多的“透传”代码，并增加延迟。在这种情况下，可酌情考虑使用 Façade 模式提供更直接的接口。
• “泄漏”的层：
  • 缓解措施：开发人员可能会为了图方便而绕过架构规则，从而削弱架构。应将所有架构违规视为导致构建失败的问题，或代码审查中的严重问题。

具体组件

此范式的实现通常会包含的工具和抽象的词汇表。它们不是依赖项，也不是 tools: frontmatter。

• dependency-validator：当某层导入超出其允许深度时，使构建失败
• layer-enforcer：静态分析门禁，用于检查命名空间是否符合层规则
• architecture-compliance-checker：将已实现的层图与文档中记录的层图进行差异比较

退出标准

• ADR 记录所选的层级堆栈（3 层、4 层或 5 层）、各层的职责、允许的依赖方向，以及跨层例外策略。
• 正式的依赖关系图已提交至项目文档，并与 ADR 中声明的层边界一致。
• 自动化架构检查（ArchUnit、dep-cruise 或同等工具）已接入 CI，并会在出现任何向上依赖时使构建失败。
• 横切关注点（日志记录、身份验证、验证）通过中间件或策略统一实现，不会在各层实现中重复。