就 DDD 而言，是否可以在域服务中为聚合根实体而不是聚合根存储库实现 crud 逻辑？

Question

嗨，我们正在实现一个基于 DDD 的框架？ 但是根据我的搜索和大多数人的想法，就最佳实践而言，聚合根 crud 逻辑应该在聚合存储库中，并且存储库应该是每个聚合根而不是每个实体。

我的意思是假设我们有两个相互依赖的实体 Order 和 OrderLine？

Order 和 OrderLine 形式聚合在一起。Aggregate Root 是 Order（这也是实体）。Orderline 是依赖于 Order 的实体。

因此，就 DDD 而言，可以有两种方法。

1)基于per aggregateroot repository的原则，我们只能有Order Repository吗？ 我们也可以拥有 genericCrudRepository。

OrderRepository orderRepo = new OrderRepository();
orderRepo.save(orderEntity);

在上述聚合根存储库的保存方法中，实现可以如下所示

genericCrudRepository.save(orderEntity);
genericCrudRepository.save(orderEntity.OrderLines);

Order和OrderLine都保存在上面的save repo方法中？

2）我们可以为 Order 和 OrderLine 提供单独的存储库吗？（每个实体的存储库）我们还可以拥有一个接受 OrderEntity 的域服务。

IOrderRepository orderRepository = new OrderRepository();

IOrderLineRepository orderLineRepository = new OrderLineRepository();

我们可以使用 IOC 容器来注入存储库依赖项。

OrderDomainService orderDomainService = new OrderDomainService(IOrderRepository orderRepository,IOrderLineRepository orderLineRepository);

orderDomainService.save(orderEntity);

Order 和 OrderLine 都保存在上面的保存域服务方法中？

域服务的保存方法的内部实现可能如下所示。

orderRepository.save(orderEntity);
orderLineRepository.save(orderEntity.OrderLines);

在域服务方面，实际上域服务是域实体的扩展，不在一个特定的聚合中。如果代码 scope 超过一个实体（这里是模糊的。这个实体还是聚合根？根据我的理解如果它超过聚合根，我们应该做域服务来实现逻辑。）

很快，像订单实体（aggregateroot）这样的聚合的 crud 逻辑可以在域服务中吗？

就 DDD 最佳实践而言，您会向我建议哪种方法？

第一还是第二？ 或其他

Answer 1

就 DDD 最佳实践而言，您会向我建议哪种方法？

DDD 往往对管道的工作方式相当沉默（定制的域模型有很多价值；但管道通常不是您的竞争优势所在）。

您的域实体不会关心（它们通常根本不与存储库交互。

我担心的是故障模式：

orderRepository.save(orderEntity);
// HOW DO YOU RECOVER FROM A CRASH BETWEEN THESE TWO LINES?
orderLineRepository.save(orderEntity.OrderLines);

有可能的答案（例如：两个存储库都参与同一个工作单元），但从查看此代码来看，它们并不明显。

特别是，可能需要将订单行和订单存储在同一位置（以便管理更改的事务可以同时控制两者）。 所以我们问 - 我们应该能够看到代码中的存储限制吗？

从我所见，“最佳实践”是编写看起来像聚合存储在一起的代码，因为有效地管理故障需要我们将聚合存储在一起——你可以认为将设计与持久性约束对齐为一种减少技术债务的方法

如果我们未能使我们的计划与我们当时理解的思考财务对象的正确方式保持一致，那么我们将不断因这种分歧而绊倒，这会使我们放慢脚步——Ward Cunningham，2009

用“持久性”代替“金融对象”。

设计是我们所做的，以获得比我们仅仅做的更多的我们想要的东西。 ——露丝·马兰

为您的情况选择合适的“我们想要的”是设计过程的重要组成部分。