首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >Java 架构:把复杂度关进边界里

Java 架构:把复杂度关进边界里

原创
作者头像
资源shanxueit.com
发布2026-09-21 15:43:59
发布2026-09-21 15:43:59
350
举报

一、架构不是框架清单

很多人谈 Java 架构,第一反应是 Spring Cloud、Redis、Kafka、分库分表。 这些是工具,不是架构本身。

Java 架构真正要回答的是:

  • 业务规则放在哪?
  • 依赖指向谁?
  • 模块边界在哪?
  • 变化来时,改一处还是改十处?

如果这些没想清楚,框架越多,系统越乱。

二、一个最小六边形骨架

先看少量代码。它不完整,但能表达核心:领域不依赖框架,应用不依赖数据库,适配器才依赖 Spring。

代码语言:javascript
复制
// domain:业务规则,不依赖 Spring / JPA
public record Order(String id, long amount) {}

public interface OrderRepository {
    void save(Order order);
}

// application:用例编排,只依赖抽象
public class PlaceOrder {
    private final OrderRepository repo;

    public PlaceOrder(OrderRepository repo) {
        this.repo = repo;
    }

    public void handle(String id, long amount) {
        if (amount <= 0) throw new IllegalArgumentException("金额必须为正");
        repo.save(new Order(id, amount));
    }
}

// adapter:框架细节,放最外层
@RestController
public class OrderController {
    private final PlaceOrder placeOrder;

    public OrderController(PlaceOrder placeOrder) {
        this.placeOrder = placeOrder;
    }

    @PostMapping("/orders")
    public void create(@RequestParam String id, @RequestParam long amount) {
        placeOrder.handle(id, amount);
    }
}

这段代码只说明一件事: 依赖方向从外向内,业务核心不被框架污染。

对应包结构也很简单:

代码语言:javascript
复制
order/
  domain/
  application/
  adapter/in/web/
  adapter/out/persistence/

三、模块化优先于微服务

Java 架构最常见的误区,是一上来就拆微服务。 但如果没有模块边界,拆成微服务只是把混乱分布到网络上。

更稳的路径是:

  1. 先做模块化单体
  2. 按业务能力划分模块
  3. 模块之间只通过接口或事件通信
  4. 等真正需要独立部署、独立扩容时,再拆服务

微服务不是默认答案,模块化才是。

四、让变化有方向

好的 Java 架构,不是预测未来,而是让变化可控:

  • 新增支付方式:加适配器,不动领域
  • 换数据库:换 repository 实现,不动用例
  • 加缓存:加装饰器,不改业务代码
  • 接消息队列:加事件发布端口,不侵入核心

架构的价值,就体现在这些“改哪里”上。

五、结论

Java 架构不是 Spring 配置大全。 它是依赖方向、模块边界和演进能力。

少量代码就能验证骨架: 领域在内,用例居中,框架在外。

剩下的,是持续守住这条边界。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

目录
  • 一、架构不是框架清单
  • 二、一个最小六边形骨架
  • 三、模块化优先于微服务
  • 四、让变化有方向
  • 五、结论
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档