本文探讨在服务层严格分离、dto 与实体完全隔离的架构中，如何安全、事务一致地持久化具有 1:1 关系的 operation 与 post 数据，重点介绍门面模式（facade）与用例聚合两种主流设计策略。
本文探讨在服务层严格分离、dto 与实体完全隔离的架构中，如何安全、事务一致地持久化具有 1:1 关系的 operation 与 post 数据，重点介绍门面模式（facade）与用例聚合两种主流设计策略。
在典型的分层架构（如 Clean Architecture 或 DDD 风格）中，服务（Service）应围绕业务能力而非数据表边界划分。然而，当 OperationService 和 PostService 已按资源维度严格解耦（各自只操作自身 DTO、不暴露实体、无直接依赖），而数据库层面又要求 Operation ↔ Post 为强制的一对一关系（例如外键约束或共享主键）时，直接跨服务持久化会破坏封装性与事务一致性。
此时，不应让任一服务承担另一领域的持久化职责（如让 OperationService 内部调用 PostService），也不应将 DTO 强制转换为实体后由 DAO 层硬编码关联——这会泄露数据细节、违背“DTO 仅用于传输”的契约。
✅ 推荐方案一：引入协调型门面（Coordinator Facade）
通过新增无业务语义、仅负责流程编排的 OperationFacade，在统一事务上下文中串联两个服务调用。该方式保持服务职责纯净，同时保障 ACID：
@Component
public class OperationFacade {
private final OperationService operationService;
private final PostService postService;
public OperationFacade(OperationService operationService, PostService postService) {
this.operationService = operationService;
this.postService = postService;
}
@Transactional // 确保整个流程原子性：成功则全提交，失败则全回滚
public void createOperation(CreateOperationDto dto) {
// Step 1: 创建 Operation，获取其生成的 ID（如自增主键或 UUID）
long operationId = operationService.create(dto.getOperation());
// Step 2: 使用该 ID 关联创建 Post（假设 Post 表含 operation_id 外键）
PostCreateDto postDto = dto.getPost();
postDto.setOperationId(operationId); // 显式注入关联标识
postService.create(postDto);
}
}⚠️ 注意事项：
- CreateOperationDto 应明确拆分为 operation 和 post 子 DTO，避免“大而全”的传输对象；
- PostService.create() 必须支持接收 operationId 参数，并将其写入 post 表的外键字段；
- 若使用共享主键（如 Post.id = Operation.id），则需在 operationService.create() 中返回可预测 ID（如 UUID），并在 postService.create() 中复用该值；
- 所有异常需统一捕获并触发事务回滚（Spring 默认支持运行时异常回滚）。
✅ 推荐方案二：重构为用例导向服务（Use Case Service）
若业务语义上“创建一个 Operation 及其专属 Post”本身就是一个不可分割的用户意图（例如“发布一条带操作说明的动态”），则更合理的建模是：撤销 OperationService/PostService 的粒度，新建 CreateOperationWithPostUseCase。它内部可协调底层仓储（Repository），直接操作实体，但对外仍仅暴露 CreateOperationDto 输入与空/成功响应输出：
@Component
public class CreateOperationWithPostUseCase {
private final OperationRepository operationRepo;
private final PostRepository postRepo;
@Transactional
public void execute(CreateOperationDto dto) {
Operation operation = new Operation(dto.getTitle(), dto.getContent());
operationRepo.save(operation); // 假设主键已生成
Post post = new Post(operation.getId(), dto.getPost().getContent());
postRepo.save(post);
}
}该方案更符合“单一职责”与“业务驱动设计”，且规避了 DTO → Entity 的手动映射成本，但需接受服务粒度从“资源”转向“行为”。
? 总结：
- 优先选择门面模式：适用于已有成熟服务且难以重构的系统，代价小、风险低；
- 长期建议用例重构：当 1:1 关系具备强业务内聚性时，用例服务能提供更清晰的契约、更强的事务控制和更低的维护复杂度；
- 永远避免：在 Controller 层手动开启事务调用两个服务、或让 DTO 携带完整实体字段绕过服务边界——这将导致架构腐化与测试困难。
