域驅動設計：處理原子操作和交易

每個聚合內部必須保證一致性。在存儲庫中執行它很容易，因爲我總是可以使用數據庫或框架中的事務。我懷疑存儲庫之外發生了什麼。服務可能需要使用多個聚合來處理請求。在服務處理過程中或聚合持續時，可能會出現問題。域驅動設計：處理原子操作和交易

如果在服務處理過程中出現問題，我可能會引發異常。這樣的操作將是原子的。這是我首先關心的問題。這是一個很好的做法嗎？我看到的問題是，它很難從中恢復。沒有簡單的方法可以讓所有聚合體保持在失敗前的狀態。

我遇到的另一個問題是如果其中一個聚合失敗，會發生什麼情況。我如何確保信息的一致性？我必須使用倉庫之外的數據庫事務嗎？我在想這可能不是最好的解決方案，因爲我在設計領域模型時不應該在數據庫中思考。

2012-07-25 Pleonc

的解決方案是在工作模式的單位提供 - http://martinfowler.com/eaaCatalog/unitOfWork.html

，只要你想你可以封裝儘可能多的聚合根操作成一個單一的UOW。然後，具體實現的工作單元可以包含它自己的提交和回滾邏輯，具體涉及持久性方法和技術。例如，如果您使用.NET，則需要處理TransactionScope對象（http://msdn.microsoft.com/en-us/library/system.transactions.transactionscope.aspx）。

下面是關於如何實現基本UOW模式像樣的文章 - http://msdn.microsoft.com/en-us/magazine/dd882510.aspx

來源

2012-07-25 20:24:21 EkoostikMartin

UOW可以解決這個問題時，一切是一臺機器上，但如果骨料可以是分佈式的，有人說分佈式事務是邪惡的事情，和我想知道在這種情況下uow是多麼的有幫助 – driushkin 2012-07-25 20:32:41

分佈式事務不是UOW或域上的任何事情的關注點。但是，在.NET中，正如我所提到的，TransactionScope處理分佈式事務。 – EkoostikMartin 2012-07-25 20:36:16

我認爲可以有一個更簡單的方法。在藍皮書中，一切都看起來簡單而完美，但實際上它很複雜。我發現，如果不使用不同的框架並實施各種東西和圖層，將實體粘合成比貧血域模型「更清晰，更簡單」的實體，則幾乎不可能實現體面的域設計。 – Pleonc 2012-07-26 01:01:20

域驅動設計：處理原子操作和交易

回答

相關問題