
很多人谈 Java 架构,第一反应是 Spring Cloud、Redis、Kafka、分库分表。 这些是工具,不是架构本身。
Java 架构真正要回答的是:
如果这些没想清楚,框架越多,系统越乱。
先看少量代码。它不完整,但能表达核心:领域不依赖框架,应用不依赖数据库,适配器才依赖 Spring。
// 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);
}
}这段代码只说明一件事: 依赖方向从外向内,业务核心不被框架污染。
对应包结构也很简单:
order/
domain/
application/
adapter/in/web/
adapter/out/persistence/Java 架构最常见的误区,是一上来就拆微服务。 但如果没有模块边界,拆成微服务只是把混乱分布到网络上。
更稳的路径是:
微服务不是默认答案,模块化才是。
好的 Java 架构,不是预测未来,而是让变化可控:
架构的价值,就体现在这些“改哪里”上。
Java 架构不是 Spring 配置大全。 它是依赖方向、模块边界和演进能力。
少量代码就能验证骨架: 领域在内,用例居中,框架在外。
剩下的,是持续守住这条边界。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。