嗨，我们正在实现一个基于DDD的框架吗?但是根据我的搜索和大多数人的想法，就最佳实践而言，聚合根crud逻辑应该在聚合存储库中，并且存储库应该是每个聚合根而不是每个实体。
我的意思是假设我们有两个实体Order和OrderLine彼此依赖?
Order和OrderLine表单聚合在一起。聚合根是Order(也是entity)。Orderline是依赖于Order的实体。
所以DDD可以有两种方法
1)我们只能有基于per aggregateroot Repository原则的Order Repository ?还有genericCrudRepository。
OrderRepository orderRepo = new OrderRepository();
orderRepo.save(orderEntity);
在上述aggregateroot存储库的保存方法中，实现如下
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都保存在上面的保存域服务方法中?
域服务的save方法的内部实现可能如下所示。
orderRepository.save(orderEntity);
orderLineRepository.save(orderEntity.OrderLines);
就域服务而言，实际上域服务是域实体的扩展，而不是一个特定的集合。如果代码范围超过一个实体(这里是模糊的)。这是实体根还是聚合根?根据我的理解，如果超过aggregateroot，我们应该做域服务来实现逻辑。
很快，像订单实体(aggregateroot)这样的聚合的crud逻辑可以在域服务中吗?
在DDD最佳实践方面，您建议我使用哪种方法?
第一还是第二?或另一个
就DDD最佳实践而言，您建议我使用哪种方法?
DDD倾向于对管道是如何工作的相当安静(定制的领域模型有很多价值;但管道通常不是你的竞争优势所在)。
您的域实体不会关心(它们通常根本不与存储库接口)。
我关心的是失效模式:
orderRepository.save(orderEntity);
// HOW DO YOU RECOVER FROM A CRASH BETWEEN THESE TWO LINES?
orderLineRepository.save(orderEntity.OrderLines);
有可能的答案(例如:两个存储库参与同一个工作单元)，但从查看这段代码来看，它们并不明显。
特别是，可能需要将订单行和订单存储在同一位置(以便管理更改的事务可以同时控制两者)。所以我们问，我们能看到代码中的存储限制吗?就我所见，"最佳实践"是编写看起来像聚合存储在一起的代码，因为有效地管理故障要求我们将聚合存储在一起——您可以考虑将设计与持久性约束对齐作为减少技术债务的一种方法
如果我们不能使我们的计划与我们所理解的正确思考我们的金融目标的方式保持一致，那么我们就会不断地被这种分歧所绊倒，这会减慢我们的速度。——沃德·坎宁安，2009
替代"persistence"为"财务目的"。
设计是我们为了得到更多我们想要的东西而做的事情，而不是仅仅做它。——露丝·马兰
选择合适的"我们想要的"对于你的环境是设计过程中很重要的一部分。