1. 从“三层”到“五层”架构演进背后的驱动力如果你在Java开发领域摸爬滚打超过三年面试时被问到“说说MVC和三层架构的区别”或者“你们项目用的是几层架构”大概率能对答如流。但如果你被追问“为什么会有四层、五层架构它们解决了三层架构的什么痛点在什么场景下必须用” 这时候很多人的回答就开始变得模糊停留在“为了解耦”、“职责分离”这些正确的废话上。今天我们不谈教科书定义就从我这些年从单体应用到复杂分布式系统趟过的坑出发掰开揉碎了聊聊Java应用架构从三层到五层的演进逻辑。这不是为了让你背八股文而是让你真正理解当你的代码库膨胀到几十万行、团队扩张到几十人时每一层新增的“隔离带”到底在保护什么以及你该如何为自己的项目选择最合适的“楼层”。架构分层本质上是一种复杂度管理和变更隔离的艺术。三层架构表现层、业务逻辑层、数据访问层是入门标配它解决了最基础的关注点分离问题。但随着业务复杂度、团队规模和系统体量的飙升三层架构内部开始出现“拥堵”和“污染”。比如业务逻辑层里塞满了各种外部服务调用和缓存逻辑导致核心业务规则被淹没又或者数据访问对象DAO里掺杂了复杂的查询逻辑和DTO转换变得臃肿不堪。这时在原有的三层之间或之内插入新的层次不是为了追求时髦而是为了应对这些实实在在的工程困境。我们常说的四层、五层架构正是这种应对策略的具体体现。接下来我会结合具体代码示例和项目场景带你一层层“盖楼”看清每一层砖瓦背后的设计意图。2. 三层架构稳固的地基与它的局限性让我们先回到起点彻底理解三层架构这个地基。很多人会把MVCModel-View-Controller和三层架构混为一谈这是第一个需要厘清的概念。MVC是一种设计模式主要关注的是用户交互的分离常见于Web框架如Spring MVC它的Controller处理请求View负责渲染Model是数据载体。而三层架构是一种更宏观的应用架构模式它关注的是整个应用职责的纵向切分。2.1 三层架构的核心构成与数据流转一个经典的三层Java Web应用通常是这样组织的表现层 (Presentation Layer / Web Layer)这是与用户可能是浏览器也可能是其他系统交互的入口。在Spring Boot项目中通常由Controller或RestController注解的类承担。它的职责非常单纯接收HTTP请求解析参数调用业务逻辑层的服务然后将处理结果封装成JSON或渲染到视图模板最后返回响应。它不应该包含任何业务规则或数据访问逻辑。业务逻辑层 (Business Logic Layer / Service Layer)这是应用的核心承载了所有的业务规则、流程控制和领域逻辑。它通常由Service注解的类实现。这一层会调用数据访问层获取或持久化数据并在此基础上进行各种计算、校验和组合。例如下单服务需要校验库存、计算价格、生成订单、扣减库存、增加用户积分这一系列操作都在这里编排。数据访问层 (Data Access Layer / Persistence Layer)负责与数据库、缓存等持久化设施打交道。通常由Repository注解的接口及其实现如MyBatis的Mapper或JPA的Repository组成。它的目标是封装所有数据操作的细节为业务逻辑层提供干净、面向对象的API。数据流转是一个清晰的单向依赖链条表现层 - 业务逻辑层 - 数据访问层。下层对上层无感知这保证了核心的业务逻辑不会因为Web框架从Spring MVC换成Vert.x或持久化框架从MyBatis换成JPA的变更而受到影响。2.2 三层架构的经典痛点业务逻辑层的“肥胖症”三层架构在中小型项目中非常高效。然而当业务爆炸式增长Service类的代码行数轻松突破上千行时问题就来了。我经历过一个促销系统核心的PromotionService有3000多行代码它至少混杂了以下几类职责核心领域逻辑如优惠券的校验、折扣计算规则。外部服务调用调用用户服务查询等级调用库存服务锁定库存调用风控服务进行校验调用消息队列发送事件。缓存操作对商品信息、用户信息进行缓存读写。数据转换与组装将多个DAO查询回来的实体Entity组合、转换成前端需要的复杂DTOData Transfer Object。// 一个“肥胖”的Service示例问题代码 Service public class OrderServiceImpl implements OrderService { Autowired private OrderDao orderDao; Autowired private UserDao userDao; Autowired private InventoryClient inventoryClient; // 外部服务Feign客户端 Autowired private RedisTemplate redisTemplate; Autowired private RabbitTemplate rabbitTemplate; Override public ComplexOrderDTO createOrder(OrderCreateVO vo) { // 1. 参数校验表现层该做的 if (vo.getUserId() null) {...} // 2. 调用外部用户服务混在核心逻辑里 UserInfo user userServiceClient.getUser(vo.getUserId()); // 3. 核心业务校验 if (!user.isActive()) {...} // 4. 调用外部库存服务 boolean locked inventoryClient.lockStock(vo.getSkuId(), vo.getQuantity()); // 5. 缓存查询 ProductDetail product (ProductDetail) redisTemplate.opsForValue().get(product: vo.getSkuId()); if (product null) { product productDao.findById(vo.getSkuId()); redisTemplate.opsForValue().set(product: vo.getSkuId(), product, 5, TimeUnit.MINUTES); } // 6. 核心计算逻辑 BigDecimal amount calculateAmount(product, vo, user); // 7. 组装订单实体并保存 Order order assembleOrder(vo, user, product, amount); orderDao.save(order); // 8. 发送领域事件消息 rabbitTemplate.convertAndSend(order.exchange, order.created, new OrderCreatedEvent(order.getId())); // 9. 组装复杂的返回DTO return assembleComplexOrderDTO(order, user, product); } // ... 其他方法 }这个类的问题一目了然它什么都做。带来的直接后果是单元测试极其困难你需要Mock数据库、Redis、消息队列、多个外部服务测试用例设置Setup代码比业务代码还长。代码复用性差缓存逻辑、外部调用逻辑散落在各个Service方法中。不利于团队协作多人修改这个巨类冲突频繁。核心领域逻辑不清晰最重要的业务规则淹没在技术细节中。三层架构的边界在这里开始模糊业务逻辑层承载了过多非核心业务的“技术关切”。这正是架构需要演进的第一个信号。3. 四层架构引入“防腐层”与“仓库模式”为了解决上述问题最常见的演进方向是在业务逻辑层和数据访问层之间进行拆分这就引出了两种主流的四层架构形态。它们的目标都是让业务逻辑层更“纯净”。3.1 形态一服务层拆分出“应用服务层”与“领域层”这是领域驱动设计DDD中常见的分层方式。它将原来的业务逻辑层一分为二应用服务层 (Application Service Layer)负责处理用例流、事务边界、安全认证、权限校验等面向用例的协调工作。它很“薄”主要工作是编排领域层的对象来完成一个具体的用户操作用例。它可以直接调用领域层也可以调用仓储层。领域层 (Domain Layer)这是应用的核心中的核心包含纯粹的领域模型和业务规则。它由实体Entity、值对象Value Object、领域服务Domain Service、领域事件Domain Event等构成。领域层应该完全独立不依赖任何其他层如数据访问、外部服务的技术实现。以前面的下单为例重构后的代码结构如下// 领域层纯粹的领域模型和规则 Entity public class Order { private OrderId id; private UserId userId; private ListOrderLine lines; private Money totalAmount; // 核心领域行为计算总价 public void calculateTotal() { this.totalAmount lines.stream().map(OrderLine::getSubTotal).reduce(Money.ZERO, Money::add); } // 核心领域规则校验订单 public void validate() { if (lines.isEmpty()) { throw new DomainException(订单项不能为空); } // ... 其他领域规则 } } // 应用服务层协调领域对象、仓储、外部服务处理用例 Service Transactional public class OrderApplicationService { Autowired private OrderRepository orderRepository; // 仓储接口属于领域层 Autowired private InventoryService inventoryService; // 外部服务防腐层接口 Autowired private EventPublisher eventPublisher; public OrderDTO createOrder(CreateOrderCommand command) { // 1. 调用外部防腐层非领域依赖 inventoryService.lockStock(command.getSkuId(), command.getQuantity()); // 2. 通过仓储获取领域实体 User user userRepository.findById(command.getUserId()); Product product productRepository.findById(command.getSkuId()); // 3. 创建领域实体核心逻辑在实体内部 Order order new Order(user.getId(), product, command.getQuantity()); order.validate(); // 调用领域规则 order.calculateTotal(); // 4. 持久化领域实体 orderRepository.save(order); // 5. 发布领域事件 eventPublisher.publish(new OrderCreatedEvent(order.getId())); // 6. 返回DTO可使用专门的Assembler return OrderAssembler.toDTO(order); } }注意这里引入的InventoryService是一个接口其实现InventoryServiceImpl会包含调用远程HTTP客户端的代码。这个实现类通常放在一个独立的“接口适配层”或“基础设施层”领域层和应用服务层只依赖于接口。这就是一种“防腐层”思想防止外部系统的变更直接污染核心业务代码。这种四层架构表现层、应用服务层、领域层、数据访问层强力地隔离了核心业务逻辑。领域层变得极其稳定且可测试因为它不依赖任何外部的东西。应用服务层虽然依赖外部但职责清晰就是协调和事务管理。3.2 形态二数据访问层演进为“仓储层”另一种四层架构更侧重于对数据访问的抽象常见于对DDD轻度应用或追求清晰架构的项目。它将传统的数据访问层DAO提升为仓储层Repository Layer。传统DAO通常是针对某个数据库表或实体的CRUD操作集合是面向数据的。仓储层是领域模型的集合它提供findById,save,findByCriteria等方法但它的语义是面向领域的。它隐藏了底层是使用MySQL、MongoDB还是内存存储。仓储接口定义在领域层实现在基础设施层。// 领域层定义的仓储接口 public interface OrderRepository { Order findById(OrderId id); OrderId save(Order order); ListOrder findByUserIdAndStatus(UserId userId, OrderStatus status); } // 基础设施层如persistence模块中的JPA实现 Repository public class JpaOrderRepository implements OrderRepository { PersistenceContext private EntityManager em; Override public Order findById(OrderId id) { return em.find(Order.class, id.getValue()); } // ... 实现其他方法可能涉及复杂的JPQL或Criteria查询 }这种分层表现层、业务逻辑层、仓储层、数据映射层/具体ORM层使得业务逻辑层不再直接依赖MyBatis的Mapper或JPA的EntityManager而是依赖一个更抽象的仓储接口。当未来需要更换持久化技术时影响范围被严格限制在基础设施层内。4. 五层架构清晰架构与六边形架构的实践当系统需要集成大量外部服务支付、风控、短信、OSS等并且对可测试性和框架独立性有极高要求时四层架构可能还不够。五层架构或者说“清洁架构”、“六边形架构”的分层思想提供了更彻底的解耦方案。4.1 核心思想依赖倒置与层次划分五层架构的核心是依赖倒置原则DIP高层模块业务逻辑不应依赖低层模块数据库、外部API二者都应依赖于抽象接口。同时抽象不应依赖于细节细节应依赖于抽象。一个典型的五层划分如下领域层 (Domain Layer)最内层包含实体、值对象、领域服务、领域事件和仓储接口。它没有任何外部依赖是纯Java对象POJO。应用服务层 (Application Layer)环绕领域层包含应用服务、DTO、用例协调器。它依赖领域层并定义对外部服务的接口需要由外层实现。接口适配层 (Interface Adapters Layer)也称为“适配器层”。它负责将外部世界Web、消息、外部API的输入转换成应用服务层能理解的命令或查询并将应用层的输出转换成外部世界能理解的格式如JSON。这里包含Controller、消息监听器、以及外部服务客户端接口的实现。基础设施层 (Infrastructure Layer)最外层包含所有技术细节的实现数据库JPA、MyBatis实现、消息队列RabbitMQ、Kafka客户端、缓存RedisTemplate、外部HTTP调用Feign、RestTemplate实现、文件存储等。它实现由内层定义的接口如仓储接口、外部服务接口。表现层/用户界面层 (Presentation/UI Layer)在Web应用中这一层有时会与接口适配层合并即Controller。在严格分层中它可能特指前端页面、移动端等。依赖方向是外层依赖内层。基础设施层实现领域层定义的仓储接口然后通过依赖注入将这个实现“注入”到应用服务层中。这样应用服务层和领域层就完全不知道JPA或MyBatis的存在。4.2 实战案例支付回调处理假设我们有一个处理支付平台异步回调的用例。在五层架构下代码组织如下// 1. 领域层 (domain) // 领域事件 public class PaymentConfirmedEvent { private OrderId orderId; private Money paidAmount; } // 仓储接口 public interface OrderRepository { Order findById(OrderId id); void save(Order order); } // 2. 应用服务层 (application) public interface PaymentService { // 定义对外部支付能力的抽象 boolean verifySignature(String callbackData); } public class ConfirmPaymentCommand { private String orderId; private String callbackData; } Service Transactional public class PaymentApplicationService { Autowired private OrderRepository orderRepository; Autowired private PaymentService paymentService; // 依赖抽象 Autowired private EventPublisher eventPublisher; public void confirmPayment(ConfirmPaymentCommand command) { // 使用抽象接口验证签名 if (!paymentService.verifySignature(command.getCallbackData())) { throw new SecurityException(签名验证失败); } Order order orderRepository.findById(new OrderId(command.getOrderId())); order.confirmPayment(); // 调用领域行为 orderRepository.save(order); eventPublisher.publish(new PaymentConfirmedEvent(order.getId(), order.getPaidAmount())); } } // 3. 接口适配层 (adapters) RestController RequestMapping(/api/callback) public class PaymentCallbackController { Autowired private PaymentApplicationService paymentAppService; PostMapping(/alipay) public String handleAlipayCallback(RequestBody String callbackData) { // 将HTTP请求适配为应用服务能理解的Command ConfirmPaymentCommand command extractCommandFromAlipayData(callbackData); paymentAppService.confirmPayment(command); return success; } } // 4. 基础设施层 (infrastructure) Component public class AlipayPaymentServiceImpl implements PaymentService { // 实现应用层定义的接口 Value(${alipay.app-id}) private String appId; Override public boolean verifySignature(String callbackData) { // 具体的支付宝签名验证逻辑可能调用支付宝SDK // 如果未来换成微信支付只需新增一个WxpayPaymentServiceImpl即可 return AlipaySignature.rsaCheckV1(...); } } Repository public class JpaOrderRepository implements OrderRepository { // JPA具体实现 }通过这种结构当支付平台从支付宝换成微信支付时你只需要在基础设施层新增一个WxpayPaymentServiceImpl并在配置中替换掉AlipayPaymentServiceImpl的注入。应用服务层PaymentApplicationService的代码一行都不用改。这就是五层架构带来的强大可维护性和可测试性领域层和应用层可以轻松进行单元测试无需启动任何外部组件。5. 如何为你的项目选择架构层级看到这里你可能会觉得五层架构很完美想立刻在新项目中使用。别急架构没有银弹分层越多复杂度也越高。选择的关键在于权衡。5.1 决策维度项目阶段、团队与复杂度项目阶段与规模初创/验证期MVP强烈建议使用经典三层架构。快速迭代、验证想法是第一要务。过早引入复杂分层是过度设计会严重拖慢开发速度。成长期核心业务稳定功能快速增加当Service类超过500行且开始频繁调用外部服务时考虑引入四层架构。将外部服务调用抽象成接口防腐层或者开始尝试按DDD思路分离应用服务和领域逻辑。成熟期/复杂系统大型单体或微服务如果系统模块多、团队规模大、外部依赖复杂超过5个重要外部系统且对长期维护和框架独立性有要求那么投资五层架构清晰架构是值得的。这在核心的领域服务或业务中台建设中尤其常见。团队能力DDD和清晰架构有较高的学习曲线。如果团队大部分成员对分层理解不深强行推行五层架构会导致开发效率低下代码风格混乱。一致的、能落地的中等水平架构优于无法正确执行的先进架构。业务复杂度和变化维度业务逻辑复杂领域规则多且经常变化适合引入领域层四层或五层将易变的规则封装在领域模型中。外部集成复杂需要对接多个供应商如多个支付渠道、多个物流公司适合引入防腐层在四层或五层中将易变的外部集成与技术细节隔离。技术栈可能变化如果未来有更换数据库、消息中间件的可能性那么仓储抽象和接口适配层就非常必要。5.2 一个实用的渐进式演进路径我的经验是不要试图在项目第一天就设计出完美的五层架构。采用渐进式演进从三层开始所有代码放在controller,service,dao(或mapper)包下。当Service臃肿时第一次拆分在service包下按功能或模块划分子包。将对外部系统的调用抽离到service下的client或adapter子包中。例如创建service/payment/alipayClient。这是向四层架构的雏形迈进。引入明确的接口为这些外部调用定义接口如PaymentService让AlipayClient去实现它。业务Service通过接口调用。此时你的结构类似于表现层 - 业务逻辑层含应用逻辑-接口层- 数据访问层/外部实现层。识别核心领域剥离领域层当某些业务实体和规则非常稳定且复杂时尝试将其抽离到一个独立的domain模块或包中包含实体、值对象和领域服务。让原来的service退化为主要做协调工作的“应用服务”。这时四层架构表现层、应用服务层、领域层、数据层就形成了。如果需要框架独立和极致测试再考虑将基础设施数据库实现、消息实现、外部SDK封装彻底剥离到最外层的infrastructure模块并通过依赖注入框架Spring将实现注入到内层。这就构成了五层架构。记住分层是手段不是目的。最终目的是为了控制复杂度提升代码的可读性、可维护性和可测试性。当你发现代码难以测试、某个变化需要修改多处、或者新人难以理解业务流时就是考虑调整架构分层的时候了。每次调整都应该能明确解决当前面临的一个或几个主要痛点而不是为了分层而分层。
Java应用架构演进：从三层到五层架构的实战解析与选型指南
发布时间：2026/7/31 6:27:11
1. 从“三层”到“五层”架构演进背后的驱动力如果你在Java开发领域摸爬滚打超过三年面试时被问到“说说MVC和三层架构的区别”或者“你们项目用的是几层架构”大概率能对答如流。但如果你被追问“为什么会有四层、五层架构它们解决了三层架构的什么痛点在什么场景下必须用” 这时候很多人的回答就开始变得模糊停留在“为了解耦”、“职责分离”这些正确的废话上。今天我们不谈教科书定义就从我这些年从单体应用到复杂分布式系统趟过的坑出发掰开揉碎了聊聊Java应用架构从三层到五层的演进逻辑。这不是为了让你背八股文而是让你真正理解当你的代码库膨胀到几十万行、团队扩张到几十人时每一层新增的“隔离带”到底在保护什么以及你该如何为自己的项目选择最合适的“楼层”。架构分层本质上是一种复杂度管理和变更隔离的艺术。三层架构表现层、业务逻辑层、数据访问层是入门标配它解决了最基础的关注点分离问题。但随着业务复杂度、团队规模和系统体量的飙升三层架构内部开始出现“拥堵”和“污染”。比如业务逻辑层里塞满了各种外部服务调用和缓存逻辑导致核心业务规则被淹没又或者数据访问对象DAO里掺杂了复杂的查询逻辑和DTO转换变得臃肿不堪。这时在原有的三层之间或之内插入新的层次不是为了追求时髦而是为了应对这些实实在在的工程困境。我们常说的四层、五层架构正是这种应对策略的具体体现。接下来我会结合具体代码示例和项目场景带你一层层“盖楼”看清每一层砖瓦背后的设计意图。2. 三层架构稳固的地基与它的局限性让我们先回到起点彻底理解三层架构这个地基。很多人会把MVCModel-View-Controller和三层架构混为一谈这是第一个需要厘清的概念。MVC是一种设计模式主要关注的是用户交互的分离常见于Web框架如Spring MVC它的Controller处理请求View负责渲染Model是数据载体。而三层架构是一种更宏观的应用架构模式它关注的是整个应用职责的纵向切分。2.1 三层架构的核心构成与数据流转一个经典的三层Java Web应用通常是这样组织的表现层 (Presentation Layer / Web Layer)这是与用户可能是浏览器也可能是其他系统交互的入口。在Spring Boot项目中通常由Controller或RestController注解的类承担。它的职责非常单纯接收HTTP请求解析参数调用业务逻辑层的服务然后将处理结果封装成JSON或渲染到视图模板最后返回响应。它不应该包含任何业务规则或数据访问逻辑。业务逻辑层 (Business Logic Layer / Service Layer)这是应用的核心承载了所有的业务规则、流程控制和领域逻辑。它通常由Service注解的类实现。这一层会调用数据访问层获取或持久化数据并在此基础上进行各种计算、校验和组合。例如下单服务需要校验库存、计算价格、生成订单、扣减库存、增加用户积分这一系列操作都在这里编排。数据访问层 (Data Access Layer / Persistence Layer)负责与数据库、缓存等持久化设施打交道。通常由Repository注解的接口及其实现如MyBatis的Mapper或JPA的Repository组成。它的目标是封装所有数据操作的细节为业务逻辑层提供干净、面向对象的API。数据流转是一个清晰的单向依赖链条表现层 - 业务逻辑层 - 数据访问层。下层对上层无感知这保证了核心的业务逻辑不会因为Web框架从Spring MVC换成Vert.x或持久化框架从MyBatis换成JPA的变更而受到影响。2.2 三层架构的经典痛点业务逻辑层的“肥胖症”三层架构在中小型项目中非常高效。然而当业务爆炸式增长Service类的代码行数轻松突破上千行时问题就来了。我经历过一个促销系统核心的PromotionService有3000多行代码它至少混杂了以下几类职责核心领域逻辑如优惠券的校验、折扣计算规则。外部服务调用调用用户服务查询等级调用库存服务锁定库存调用风控服务进行校验调用消息队列发送事件。缓存操作对商品信息、用户信息进行缓存读写。数据转换与组装将多个DAO查询回来的实体Entity组合、转换成前端需要的复杂DTOData Transfer Object。// 一个“肥胖”的Service示例问题代码 Service public class OrderServiceImpl implements OrderService { Autowired private OrderDao orderDao; Autowired private UserDao userDao; Autowired private InventoryClient inventoryClient; // 外部服务Feign客户端 Autowired private RedisTemplate redisTemplate; Autowired private RabbitTemplate rabbitTemplate; Override public ComplexOrderDTO createOrder(OrderCreateVO vo) { // 1. 参数校验表现层该做的 if (vo.getUserId() null) {...} // 2. 调用外部用户服务混在核心逻辑里 UserInfo user userServiceClient.getUser(vo.getUserId()); // 3. 核心业务校验 if (!user.isActive()) {...} // 4. 调用外部库存服务 boolean locked inventoryClient.lockStock(vo.getSkuId(), vo.getQuantity()); // 5. 缓存查询 ProductDetail product (ProductDetail) redisTemplate.opsForValue().get(product: vo.getSkuId()); if (product null) { product productDao.findById(vo.getSkuId()); redisTemplate.opsForValue().set(product: vo.getSkuId(), product, 5, TimeUnit.MINUTES); } // 6. 核心计算逻辑 BigDecimal amount calculateAmount(product, vo, user); // 7. 组装订单实体并保存 Order order assembleOrder(vo, user, product, amount); orderDao.save(order); // 8. 发送领域事件消息 rabbitTemplate.convertAndSend(order.exchange, order.created, new OrderCreatedEvent(order.getId())); // 9. 组装复杂的返回DTO return assembleComplexOrderDTO(order, user, product); } // ... 其他方法 }这个类的问题一目了然它什么都做。带来的直接后果是单元测试极其困难你需要Mock数据库、Redis、消息队列、多个外部服务测试用例设置Setup代码比业务代码还长。代码复用性差缓存逻辑、外部调用逻辑散落在各个Service方法中。不利于团队协作多人修改这个巨类冲突频繁。核心领域逻辑不清晰最重要的业务规则淹没在技术细节中。三层架构的边界在这里开始模糊业务逻辑层承载了过多非核心业务的“技术关切”。这正是架构需要演进的第一个信号。3. 四层架构引入“防腐层”与“仓库模式”为了解决上述问题最常见的演进方向是在业务逻辑层和数据访问层之间进行拆分这就引出了两种主流的四层架构形态。它们的目标都是让业务逻辑层更“纯净”。3.1 形态一服务层拆分出“应用服务层”与“领域层”这是领域驱动设计DDD中常见的分层方式。它将原来的业务逻辑层一分为二应用服务层 (Application Service Layer)负责处理用例流、事务边界、安全认证、权限校验等面向用例的协调工作。它很“薄”主要工作是编排领域层的对象来完成一个具体的用户操作用例。它可以直接调用领域层也可以调用仓储层。领域层 (Domain Layer)这是应用的核心中的核心包含纯粹的领域模型和业务规则。它由实体Entity、值对象Value Object、领域服务Domain Service、领域事件Domain Event等构成。领域层应该完全独立不依赖任何其他层如数据访问、外部服务的技术实现。以前面的下单为例重构后的代码结构如下// 领域层纯粹的领域模型和规则 Entity public class Order { private OrderId id; private UserId userId; private ListOrderLine lines; private Money totalAmount; // 核心领域行为计算总价 public void calculateTotal() { this.totalAmount lines.stream().map(OrderLine::getSubTotal).reduce(Money.ZERO, Money::add); } // 核心领域规则校验订单 public void validate() { if (lines.isEmpty()) { throw new DomainException(订单项不能为空); } // ... 其他领域规则 } } // 应用服务层协调领域对象、仓储、外部服务处理用例 Service Transactional public class OrderApplicationService { Autowired private OrderRepository orderRepository; // 仓储接口属于领域层 Autowired private InventoryService inventoryService; // 外部服务防腐层接口 Autowired private EventPublisher eventPublisher; public OrderDTO createOrder(CreateOrderCommand command) { // 1. 调用外部防腐层非领域依赖 inventoryService.lockStock(command.getSkuId(), command.getQuantity()); // 2. 通过仓储获取领域实体 User user userRepository.findById(command.getUserId()); Product product productRepository.findById(command.getSkuId()); // 3. 创建领域实体核心逻辑在实体内部 Order order new Order(user.getId(), product, command.getQuantity()); order.validate(); // 调用领域规则 order.calculateTotal(); // 4. 持久化领域实体 orderRepository.save(order); // 5. 发布领域事件 eventPublisher.publish(new OrderCreatedEvent(order.getId())); // 6. 返回DTO可使用专门的Assembler return OrderAssembler.toDTO(order); } }注意这里引入的InventoryService是一个接口其实现InventoryServiceImpl会包含调用远程HTTP客户端的代码。这个实现类通常放在一个独立的“接口适配层”或“基础设施层”领域层和应用服务层只依赖于接口。这就是一种“防腐层”思想防止外部系统的变更直接污染核心业务代码。这种四层架构表现层、应用服务层、领域层、数据访问层强力地隔离了核心业务逻辑。领域层变得极其稳定且可测试因为它不依赖任何外部的东西。应用服务层虽然依赖外部但职责清晰就是协调和事务管理。3.2 形态二数据访问层演进为“仓储层”另一种四层架构更侧重于对数据访问的抽象常见于对DDD轻度应用或追求清晰架构的项目。它将传统的数据访问层DAO提升为仓储层Repository Layer。传统DAO通常是针对某个数据库表或实体的CRUD操作集合是面向数据的。仓储层是领域模型的集合它提供findById,save,findByCriteria等方法但它的语义是面向领域的。它隐藏了底层是使用MySQL、MongoDB还是内存存储。仓储接口定义在领域层实现在基础设施层。// 领域层定义的仓储接口 public interface OrderRepository { Order findById(OrderId id); OrderId save(Order order); ListOrder findByUserIdAndStatus(UserId userId, OrderStatus status); } // 基础设施层如persistence模块中的JPA实现 Repository public class JpaOrderRepository implements OrderRepository { PersistenceContext private EntityManager em; Override public Order findById(OrderId id) { return em.find(Order.class, id.getValue()); } // ... 实现其他方法可能涉及复杂的JPQL或Criteria查询 }这种分层表现层、业务逻辑层、仓储层、数据映射层/具体ORM层使得业务逻辑层不再直接依赖MyBatis的Mapper或JPA的EntityManager而是依赖一个更抽象的仓储接口。当未来需要更换持久化技术时影响范围被严格限制在基础设施层内。4. 五层架构清晰架构与六边形架构的实践当系统需要集成大量外部服务支付、风控、短信、OSS等并且对可测试性和框架独立性有极高要求时四层架构可能还不够。五层架构或者说“清洁架构”、“六边形架构”的分层思想提供了更彻底的解耦方案。4.1 核心思想依赖倒置与层次划分五层架构的核心是依赖倒置原则DIP高层模块业务逻辑不应依赖低层模块数据库、外部API二者都应依赖于抽象接口。同时抽象不应依赖于细节细节应依赖于抽象。一个典型的五层划分如下领域层 (Domain Layer)最内层包含实体、值对象、领域服务、领域事件和仓储接口。它没有任何外部依赖是纯Java对象POJO。应用服务层 (Application Layer)环绕领域层包含应用服务、DTO、用例协调器。它依赖领域层并定义对外部服务的接口需要由外层实现。接口适配层 (Interface Adapters Layer)也称为“适配器层”。它负责将外部世界Web、消息、外部API的输入转换成应用服务层能理解的命令或查询并将应用层的输出转换成外部世界能理解的格式如JSON。这里包含Controller、消息监听器、以及外部服务客户端接口的实现。基础设施层 (Infrastructure Layer)最外层包含所有技术细节的实现数据库JPA、MyBatis实现、消息队列RabbitMQ、Kafka客户端、缓存RedisTemplate、外部HTTP调用Feign、RestTemplate实现、文件存储等。它实现由内层定义的接口如仓储接口、外部服务接口。表现层/用户界面层 (Presentation/UI Layer)在Web应用中这一层有时会与接口适配层合并即Controller。在严格分层中它可能特指前端页面、移动端等。依赖方向是外层依赖内层。基础设施层实现领域层定义的仓储接口然后通过依赖注入将这个实现“注入”到应用服务层中。这样应用服务层和领域层就完全不知道JPA或MyBatis的存在。4.2 实战案例支付回调处理假设我们有一个处理支付平台异步回调的用例。在五层架构下代码组织如下// 1. 领域层 (domain) // 领域事件 public class PaymentConfirmedEvent { private OrderId orderId; private Money paidAmount; } // 仓储接口 public interface OrderRepository { Order findById(OrderId id); void save(Order order); } // 2. 应用服务层 (application) public interface PaymentService { // 定义对外部支付能力的抽象 boolean verifySignature(String callbackData); } public class ConfirmPaymentCommand { private String orderId; private String callbackData; } Service Transactional public class PaymentApplicationService { Autowired private OrderRepository orderRepository; Autowired private PaymentService paymentService; // 依赖抽象 Autowired private EventPublisher eventPublisher; public void confirmPayment(ConfirmPaymentCommand command) { // 使用抽象接口验证签名 if (!paymentService.verifySignature(command.getCallbackData())) { throw new SecurityException(签名验证失败); } Order order orderRepository.findById(new OrderId(command.getOrderId())); order.confirmPayment(); // 调用领域行为 orderRepository.save(order); eventPublisher.publish(new PaymentConfirmedEvent(order.getId(), order.getPaidAmount())); } } // 3. 接口适配层 (adapters) RestController RequestMapping(/api/callback) public class PaymentCallbackController { Autowired private PaymentApplicationService paymentAppService; PostMapping(/alipay) public String handleAlipayCallback(RequestBody String callbackData) { // 将HTTP请求适配为应用服务能理解的Command ConfirmPaymentCommand command extractCommandFromAlipayData(callbackData); paymentAppService.confirmPayment(command); return success; } } // 4. 基础设施层 (infrastructure) Component public class AlipayPaymentServiceImpl implements PaymentService { // 实现应用层定义的接口 Value(${alipay.app-id}) private String appId; Override public boolean verifySignature(String callbackData) { // 具体的支付宝签名验证逻辑可能调用支付宝SDK // 如果未来换成微信支付只需新增一个WxpayPaymentServiceImpl即可 return AlipaySignature.rsaCheckV1(...); } } Repository public class JpaOrderRepository implements OrderRepository { // JPA具体实现 }通过这种结构当支付平台从支付宝换成微信支付时你只需要在基础设施层新增一个WxpayPaymentServiceImpl并在配置中替换掉AlipayPaymentServiceImpl的注入。应用服务层PaymentApplicationService的代码一行都不用改。这就是五层架构带来的强大可维护性和可测试性领域层和应用层可以轻松进行单元测试无需启动任何外部组件。5. 如何为你的项目选择架构层级看到这里你可能会觉得五层架构很完美想立刻在新项目中使用。别急架构没有银弹分层越多复杂度也越高。选择的关键在于权衡。5.1 决策维度项目阶段、团队与复杂度项目阶段与规模初创/验证期MVP强烈建议使用经典三层架构。快速迭代、验证想法是第一要务。过早引入复杂分层是过度设计会严重拖慢开发速度。成长期核心业务稳定功能快速增加当Service类超过500行且开始频繁调用外部服务时考虑引入四层架构。将外部服务调用抽象成接口防腐层或者开始尝试按DDD思路分离应用服务和领域逻辑。成熟期/复杂系统大型单体或微服务如果系统模块多、团队规模大、外部依赖复杂超过5个重要外部系统且对长期维护和框架独立性有要求那么投资五层架构清晰架构是值得的。这在核心的领域服务或业务中台建设中尤其常见。团队能力DDD和清晰架构有较高的学习曲线。如果团队大部分成员对分层理解不深强行推行五层架构会导致开发效率低下代码风格混乱。一致的、能落地的中等水平架构优于无法正确执行的先进架构。业务复杂度和变化维度业务逻辑复杂领域规则多且经常变化适合引入领域层四层或五层将易变的规则封装在领域模型中。外部集成复杂需要对接多个供应商如多个支付渠道、多个物流公司适合引入防腐层在四层或五层中将易变的外部集成与技术细节隔离。技术栈可能变化如果未来有更换数据库、消息中间件的可能性那么仓储抽象和接口适配层就非常必要。5.2 一个实用的渐进式演进路径我的经验是不要试图在项目第一天就设计出完美的五层架构。采用渐进式演进从三层开始所有代码放在controller,service,dao(或mapper)包下。当Service臃肿时第一次拆分在service包下按功能或模块划分子包。将对外部系统的调用抽离到service下的client或adapter子包中。例如创建service/payment/alipayClient。这是向四层架构的雏形迈进。引入明确的接口为这些外部调用定义接口如PaymentService让AlipayClient去实现它。业务Service通过接口调用。此时你的结构类似于表现层 - 业务逻辑层含应用逻辑-接口层- 数据访问层/外部实现层。识别核心领域剥离领域层当某些业务实体和规则非常稳定且复杂时尝试将其抽离到一个独立的domain模块或包中包含实体、值对象和领域服务。让原来的service退化为主要做协调工作的“应用服务”。这时四层架构表现层、应用服务层、领域层、数据层就形成了。如果需要框架独立和极致测试再考虑将基础设施数据库实现、消息实现、外部SDK封装彻底剥离到最外层的infrastructure模块并通过依赖注入框架Spring将实现注入到内层。这就构成了五层架构。记住分层是手段不是目的。最终目的是为了控制复杂度提升代码的可读性、可维护性和可测试性。当你发现代码难以测试、某个变化需要修改多处、或者新人难以理解业务流时就是考虑调整架构分层的时候了。每次调整都应该能明确解决当前面临的一个或几个主要痛点而不是为了分层而分层。
