java - 带有 Spring 的 DDD Java - 返回 Mono/Flux 的存储库

Question

我想知道在我使用 Java 和 Spring Boot 实现的 DDD 项目中实现反应式 Mongo 存储库时遇到的一个问题。假设我们有这样的包结构：

/app 
  |
  |------/application
  |        | 
  |        |------/order
  |                 |
  |                 |------OrderApplicationService.java
  |
  |------/domain
  |        |
  |        |------/order
  |                 |
  |                 |------Order.java
  |                 |------OrderRepository.java 
  |
  |------/infrastructure
           |
           |------/mongo
                    |
                    |------MongoOrderRepository.java

我的 OrderRepository.java 我想要一个方法来保存我的订单：

public interface OrderRepository {

    Order save(Order order);
}

并在我的应用程序服务中使用它：

@Service
public class OrderApplicationService {

    private final OrderRepository orderRepository;

    public OrderApplicationService(OrderRepository orderRepository) {
        this.orderRepository = orderRepository;
    }

    public void createOrder() {
        //Dumb order creation
        Order createdOrder = clientRepository.save(new Order());
    }
}

接下来我想编写实现 OrderRepository 的 MongoOrderRepository。假设我将使用 ReactiveMongoTemplate。问题是它的所有方法都返回 Flux 或 Mono，所以我无法从 OrderRepository 接口实现我的方法。

我看到的可能的解决方案是：

1. 使 OrderRepository 中的“保存”方法返回一个由 Mono 包装的订单。这种方法将使用 Reactor 特定类型污染领域层，并打破领域层应该是框架代码自由的规则。
2. 开发某种包装层，但这会产生一些样板代码。
3. 将 OrderService.java 移至基础设施层，但这也打破了一些基本的 DDD 概念。

有人看到更好的解决方案吗？

标签： javaspringmongodbdomain-driven-designproject-reactor

Answer 1

存储库应该与框架代码无关，这是正确的，这是一种很好的做法，但您也需要务实，我有使用 java lambda 的存储库，这是一种可以争论的语言级框架。

使用 Flux 或 Mono 有什么好处，将它们作为界面的一部分进行宣传有什么好处？如果没有，您可以将实现细节保存到存储库实现中，并保持接口没有反应性对象。

但是，如果这需要跨越应用程序层到端口适配器，那么我认为将它们放入存储库的接口定义中没有任何问题。

话虽如此，您可能想检查另一种方法，使用 CQRS 和六边形架构，您可以两全其美：

• 为命令提供干净的存储库界面（更新和创建部分）

• 使用查询服务（如果您在 java 中，则使用普通 POJO，在您的应用程序包中定义）为查询返回 Mono 或 Flux（阅读部分）

  OrderApplicationService.java（这里是通过命令创建更新删除） OrderQueryService.java（这里是读取部分）

您的应用程序服务包含对您的 OrderRepository 的引用，查询服务不使用存储库，因为它更直接地查询数据库，例如通过 ReactiveMongoTemplate。

例如，在我的查询服务中，我使用了普通的 JDBC 模板，而在存储库实现中使用了 Hibernate。