分层架构是什么
分层架构按技术职责把系统切成若干层，常见划分是表现层、业务层、持久层与数据库层，上层依赖下层、下层不反向依赖上层。封闭层要求请求逐层经过，隔离性更好；开放层允许上层跳过中间层，减少透传开销但耦合上升。它是最通用的架构风格，实现简单、上手快，代价是改动常常要穿过整条链路，层数过多时大量请求只是在逐层透传。
基本信息
| 层次示例 | 表现层 → 业务层 → 持久层 → 数据库 |
|---|---|
| 封闭层 | 禁止跨层调用，隔离性更好，测试更独立 |
| 开放层 | 允许上层跳过中间层，减少透传损耗 |
| 依赖方向 | 单向向下，下层不得反向依赖上层 |
| 常见落地 | 单体应用、MVC 框架应用、后台管理系统 |
分层职责与违规
| 层 | 职责 | 常见违规 |
|---|---|---|
| 表现层 | 参数校验、会话管理、视图编排 | 直接拼 SQL 或内嵌业务规则 |
| 业务层 | 业务规则与事务边界 | 依赖 Web 上下文对象，无法独立测试 |
| 持久层 | 对象映射与查询组装 | 向上层返回框架专有实体 |
| 数据库层 | schema、约束与索引 | 用触发器承担业务规则，逻辑不可见 |
典型使用场景
- 中小型业务系统：团队规模小、变更节奏平稳，分层收益高于分布式复杂度
- 系统起步阶段：先把结构与依赖方向立住，为后续拆分留出边界
- 企业后台与管理系统：以表单和流程为主，分层足以支撑
- 模块化改造前：先用分层隔离技术细节，再按业务域重划分包
- 教学与评审：用分层讲清依赖方向与职责边界，直观易懂
- 合规审计场景：分层便于做代码扫描与越权访问检查
判断分层是否失效看两点：请求是否大量逐层透传、业务规则是否散落在表现层与触发器里；出现任意一种就该调整边界而不是继续加层。
分层是技术维度切分，不解决业务边界问题；同一个业务流程仍会横跨所有层，因此高频变更的系统常需要向按业务域划分的方式演进。