第28章分层架构

课程目录第28章分层架构

第28章分层架构：从混乱到有序的必修课

说实话，我见过太多项目一开始就乱成一锅粥。代码东一块西一块，业务逻辑和数据库查询混在一起，前端页面里直接写SQL。嗯，这种项目维护起来，简直是一场噩梦。

分层架构，就是用来解决这个问题的。它不是什么高深的理论，说白了就是一句话：把不同职责的代码，放到不同的层里。

什么是分层架构？

分层架构的核心思想，是关注点分离。每一层只关心自己的事，不越界。上层依赖下层，下层不依赖上层。这样改一层，不会影响到其他层。

我习惯把分层架构比作一个公司的组织架构。前台接待客户，中台处理业务，后台管财务。各司其职，出了问题也好追责。

  核心定义： 分层架构是一种将系统按职责划分为多个水平层次的软件架构模式。每一层为其上层提供服务，并调用下层的接口。

分层原则：三条铁律

做分层架构，有三条原则我建议你刻在脑子里：

单向依赖：上层只能依赖下层，不能反过来。表现层依赖业务层，业务层依赖数据层。一旦出现循环依赖，分层的意义就没了。
封装性：每一层的内部实现对外部是黑盒。你调用业务层的方法，不需要知道它底层是查MySQL还是Redis。
抽象接口：层与层之间通过接口通信，而不是直接耦合具体实现。这样换数据库、换UI框架，都只需要改一层。

我曾经踩过的坑： 有个项目，业务层直接new了一个数据访问层的具体类。后来要换ORM框架，结果业务层代码改了一大片。从那以后，我强制团队所有层间调用必须走接口。

经典三层架构

最经典的分层架构，就是三层架构。它把系统分成三块：

表现层（UI层）：负责和用户交互。展示数据、接收输入。可以是Web页面、移动端界面，也可以是API接口。
业务逻辑层（BLL层）：核心业务处理。校验规则、计算逻辑、流程控制。这一层是系统的灵魂。
数据访问层（DAL层）：和数据库打交道。增删改查、事务管理。不包含任何业务逻辑。

来看一个简单的代码示例，你就明白了：

// 表现层：控制器
public class UserController {
    private UserService userService;

    public User getUser(int id) {
        return userService.getUserById(id);
    }
}

// 业务逻辑层：服务
public class UserService {
    private UserRepository userRepository;

    public User getUserById(int id) {
        // 业务校验：用户ID不能为负数
        if (id < 0) {
            throw new IllegalArgumentException("无效的用户ID");
        }
        return userRepository.findById(id);
    }
}

// 数据访问层：仓库
public class UserRepository {
    private Database db;

    public User findById(int id) {
        return db.query("SELECT * FROM users WHERE id = ?", id);
    }
}

你看，每一层的职责非常清晰。表现层只管接收请求和返回结果，业务层做校验和逻辑，数据层只负责查询。改数据库，只需要改UserRepository；改前端展示，只需要改UserController。

优缺点分析

优点	缺点
结构清晰，易于理解和维护	层数增加，性能有损耗（每层调用都有开销）
团队可以并行开发不同层	简单功能也可能需要穿过所有层，显得繁琐
某一层可以独立替换（如换数据库）	层与层之间如果耦合过紧，分层优势就没了
便于测试（可以mock下层接口）	对于非常简单的系统，分层反而增加复杂度

我的建议： 不要为了分层而分层。如果项目只有几千行代码，一个简单的MVC就够了。但一旦业务复杂到需要多人维护，分层架构就是必需品。

应用场景

分层架构适合哪些场景？我总结了几类：

企业级应用：ERP、CRM、OA这类系统，业务逻辑复杂，需要多人协作开发。分层架构是标配。
需要长期维护的项目：如果你知道这个系统要跑5年、10年，分层能帮你降低维护成本。
多端支持：同一个业务层，可以同时支撑Web端、移动端、第三方API。你想想看，这多省事。
团队分工明确：前端团队负责表现层，后端团队负责业务层，DBA负责数据层。各干各的，互不干扰。

但也要注意，不是所有项目都适合。比如一个简单的博客系统，或者一个内部小工具，用分层架构反而显得臃肿。我见过有人写个几百行的脚本也硬要分三层，结果代码量翻了三倍，维护起来更麻烦。

知识体系结构图

下面这张图，帮你把分层架构的核心脉络理清楚：

最后说几句

分层架构不是什么银弹。它解决的是复杂系统的组织问题，而不是性能问题。如果你发现系统因为分层太多导致调用链路过长，可以考虑用依赖注入、接口抽象来优化，或者适当合并一些层。

我个人习惯是：先分层，再优化。先把结构搭好，让代码可读、可维护，然后再针对热点路径做性能调优。千万别反过来，为了性能把代码写成一团乱麻。

嗯，分层架构就讲到这里。记住一句话：好的架构，是让未来的你少加班。

📚 课程目录