聚合是否應該在數據庫中引入讀鎖？

Question

我讀埃裏克埃文斯書約DDD，章骨料。

當訂單/訂單行處理例如，它指出：

當兩個用戶保存他們的變化，訂單將被存儲在違反域模型的不變的 數據庫。一個重要的商業規則 已被打破。甚至沒有人知道。顯然，鎖定 單個項目並不是一個足夠的保障措施。 如果我們在時間鎖定了 整個訂單，問題就會被阻止。

我知道Aggregate的本質是用單個包裝的數據庫事務來保護不變量。

但是，是否應該在數據庫端上指定以防止潛在的併發問題（爭用條件），同時由多個用戶同時修改此聚合？

正在一個總量的收集在數據庫端的讀鎖一些元素的真正意義？

對此的任何澄清都會讓我開心。

Answer 1

不，這兩者是正交的：

總設計的目標是到邊界內建立一個連貫的邊界和保護不變。鎖定設計的目標是在應用程序內啓用合適的併發水平。

這意味着，在相同的聚集設計，不同的鎖定機制可能是有意義的（這取決於應用程序的非功能性需求）。

Answer 2

我知道Aggregate的本質是用單個包裝數據庫事務來保護不變量 。

是嗎？聚合根在他們自己的不變量周圍是一致的邊界。考慮到在一個完全不同的流程中發生在網絡上的持久性，流程中的聚合體如何希望能夠保證圍繞不受其控制的事物的一致性？

DDD的本質是分離領域和基礎設施問題;骨料應在域建模（訂單，產品，客戶）和其他一切（數據庫，持久性，鎖定交易）來表述的是基礎設施，不應該被污染你的域模型。