就 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

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

設計是我們所做的，以獲得比我們僅僅做的更多的我們想要的東西。 ——露絲·馬蘭

為您的情況選擇合適的“我們想要的”是設計過程的重要組成部分。