Clean Architecture+Spring Boot微服务：领域层与持久化层问题咨询

关于这种实现方式的普遍性 #

这种将domain、application层与Spring框架完全隔离，仅在infrastructure层引入Spring及ORM依赖的Clean Architecture实现方式，是行业内非常主流的实践。它严格遵循了Clean Architecture的依赖规则，确保领域核心逻辑不被框架细节污染，具备良好的可测试性和可扩展性。

问题一：DomainModel与JpaEntity的重复转换 #

频繁的模型转换确实是这种分层方式的常见“副作用”，可以通过以下方式优化：

• 使用映射工具简化转换逻辑：比如MapStruct，它可以自动生成类型安全的转换代码，避免手动编写大量get/set代码。只需要在infrastructure层定义映射接口，让工具自动实现转换，既不污染领域层，又能减少重复劳动。
• 明确转换边界：转换逻辑只存在于infrastructure层的适配器中，application和domain层完全不感知JpaEntity的存在。这虽然增加了一层转换，但换来了领域层的纯净，是值得的 trade-off。

问题二：乐观锁Version字段的测试与架构冲突 #

乐观锁是数据库层面的技术实现细节，确实不应该暴露到domain层。解决思路如下：

• 直接测试适配器层：既然乐观锁逻辑是JpaEntity的特性，你可以编写针对DomainModelJpaAdapter的集成测试，在测试中直接操作JpaEntity来验证乐观锁的触发逻辑，无需通过领域模型。比如模拟并发修改同一实体，验证是否抛出OptimisticLockingFailureException。
• 转换技术异常为领域异常：在适配器捕获JPA的乐观锁异常，将其转换为domain层定义的自定义业务异常（比如ConcurrentResourceModificationException）。这样application层可以感知到并发修改的业务场景，但不需要知道Version字段的存在，完全符合架构原则。

关于application层是否允许引入Spring依赖 #

严格遵循Clean Architecture的话，不建议让application层依赖Spring框架。原因是：

• Clean Architecture要求内层（domain、application）不依赖外层（infrastructure）的框架或技术，这样application层的核心逻辑可以在不同框架下复用，比如换成Quarkus或者纯Java应用时不需要修改application层代码。
• 如果只是想使用Spring的一些工具类，建议封装成独立的工具模块，让application层依赖这个工具模块而非直接依赖Spring，保持依赖的纯净性。
• 例外情况：如果你的项目明确不需要跨框架复用，且团队接受一定的架构妥协，也可以在application层引入Spring的轻量依赖（比如spring-context），但这会降低架构的灵活性，需要谨慎权衡。

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