Java 架构：用少量代码理解分层与解耦

架构不是堆砌框架，而是控制依赖的方向。一行接口，往往比一千行配置更能决定系统的可维护性。

一、为什么 Java 架构总在谈分层

绝大多数 Java 项目最终都会长成类似的样子：

• Controller：接收请求，参数校验，返回响应
• Service：业务逻辑，事务边界
• Repository：数据访问，屏蔽数据库细节
• Entity / DTO：数据载体，跨层传输

分层的本质是关注点分离。但仅仅分层还不够，如果 Controller 直接依赖具体的 Service 实现，Service 直接依赖具体的 Repository 实现，代码依然会紧耦合，难以测试和替换。

真正的架构功力，体现在依赖倒置：高层模块不依赖低层模块，两者都依赖抽象。

二、少量代码：依赖倒置的最小示例

下面这段 Java 代码不到 15 行，却展示了架构中最核心的解耦手法。

interface UserRepository {
    User findById(Long id);
}

class UserService {
    private final UserRepository repo;
    UserService(UserRepository repo) { this.repo = repo; }
    User getUser(Long id) { return repo.findById(id); }
}

class MySqlUserRepository implements UserRepository {
    public User findById(Long id) { /* 查数据库 */ return new User(); }
}

class InMemoryUserRepository implements UserRepository {
    public User findById(Long id) { /* 查内存 */ return new User(); }
}

UserService 不关心数据来自 MySQL 还是内存，它只依赖 UserRepository 接口。这样：

• 单元测试可以注入 InMemoryUserRepository，无需启动数据库
• 更换存储只需新增实现，不改业务代码
• 未来拆分微服务时，UserRepository 可以变成远程调用客户端

这就是架构的杠杆效应：用抽象隔离变化。

三、从单体到微服务，原则不变

很多人以为微服务是架构的终极目标，其实它只是分层和依赖倒置在分布式场景下的延伸。

• 单体：模块间通过接口解耦，为拆分做准备
• 微服务：服务间通过 API 契约解耦，本质仍是依赖抽象
• 事件驱动：服务间通过事件解耦，依赖的是消息格式而非具体服务

无论架构如何演进，核心始终是：控制依赖方向，让变化点局部化。

四、Java 架构的四个实战建议

1. 接口属于调用方 接口定义在高层模块中，实现放在低层。这样高层不需要知道低层细节。
2. 包结构反映架构 按领域或功能分包，而不是按技术分层（如 controller、service、dao）。领域包内聚，层间通过接口通信。
3. 依赖注入是手段，不是目的 Spring 的 @Autowired 很方便，但不要为了注入而注入。构造函数注入 + final 字段，能强制依赖不可变。
4. 架构守护靠测试 用 ArchUnit 等工具写测试，防止“Service 直接调 Controller”这类依赖倒置违规。

五、结语

Java 架构的复杂度，往往来自过度设计和依赖失控。 先用少量代码把依赖倒置跑通，再逐步引入框架、微服务和分布式组件。 好的架构不是画出来的，而是通过一次次解耦，让系统在变化面前保持从容。