六边形Java应用中@Transactional注解应置于哪个包？

架构背景 #

你的Java应用采用六边形架构，各包职责划分如下：

• core包：承载纯业务逻辑，以普通Java对象（POJO）和业务接口形式存在，无任何技术依赖
• api包：作为外部端口，接收REST请求，调用核心业务逻辑接口完成实体检索、创建等操作
• persistency包：作为基础设施适配器，实现核心定义的持久化接口，负责数据库的增删改查，与核心层完全解耦

核心问题 #

哪个组件最适合管理数据库事务？具体到Spring Boot中，哪个包应包含标注@Transactional的方法？

常见思路的利弊分析 #

1. 放在core包 #

• 看似合理：事务回滚是保障业务数据一致性的核心需求
• 弊端：事务是数据库特有的技术细节，若后续将持久化适配器替换为REST存储等非数据库方案，@Transactional注解完全失效，违背六边形架构“核心与技术细节隔离”的原则

2. 放在api包（控制器层） #

• 非分层架构中的常见做法：REST端点决定请求的完整存储逻辑
• 弊端：让作为外部边界的API层管理持久化细节，不符合六边形架构的职责划分；当核心对接不同持久化方式时，注解会直接失效

3. 放在persistency包 #

• 思路：事务是持久化层的技术细节，由适配器自行管理
• 弊端：无法控制全局事务粒度，多次数据库访问会被拆分为独立事务，无法保证跨操作的原子性（比如创建订单+扣减库存的组合操作）

推荐方案 #

方案1：引入应用服务层（最贴合六边形架构） #

在core包之外、api和persistency之间新增应用服务层（比如application包），该层负责：

• 编排核心业务逻辑
• 调用persistency适配器的持久化接口
• 控制事务边界，在应用服务类的方法上标注@Transactional

优势：

• 核心层（core）保持纯业务逻辑，不涉及任何技术细节
• 事务控制由负责协调业务与基础设施的应用层承担，职责清晰
• 适配不同持久化方案时，只需替换persistency适配器，事务逻辑的调整也局限在应用层或适配器层，不影响核心

方案2：在核心层业务服务类添加@Transactional（简化版） #

若不想新增应用层，可在core包的业务服务实现类（依赖核心持久化接口的类）上标注@Transactional，但需注意：

• 核心层的业务接口仍保持纯业务定义，不依赖Spring注解
• @Transactional是Spring通过AOP织入的技术增强，核心业务逻辑本身不感知它
• 若后续更换非数据库的持久化方案，只需移除该注解或替换事务实现，核心业务逻辑无需修改

方案3：通过事务端口解耦（严格六边形架构） #

• 在core包中定义抽象的TransactionManagerPort接口，包含begin()、commit()、rollback()等方法，核心业务逻辑通过该接口控制事务边界
• 在persistency包中实现该端口，用Spring的PlatformTransactionManager或@Transactional完成具体的事务操作
• 优势：核心层完全与事务技术细节解耦，更换持久化方案时只需替换端口实现

内容的提问来源于stack exchange，提问作者Florian