DDD CQRS併發問題

我們已經建立了基於DDD和CQRS的體系結構。此外，我們還有一個安靜的API，可以讓我們的客戶連接到一個OAUTH實現。我們的客戶連接到我們的API並代表他們的客戶執行操作。他們的客戶由我們的配置文件代表。DDD CQRS併發問題

對於下列問題，我們沒有很好的解決方案。客戶可以通過調用API的方法來創建配置文件。問題是我們需要保證配置文件的唯一性。因此，我們目前所做的是檢查讀取模型中的現有配置文件，如果該命令不存在，則創建一個命令並將配置文件ID返回給客戶端，以便它們可以執行其他API調用。

當客戶端快速連續執行多個調用時，由於過期的讀取模型，配置文件會創建兩次而不是一次。我們不希望這樣，但我們如何解決這個問題？

我們曾想過創建一個傳奇以防止在域中創建多個配置文件，但這仍然存在問題，因爲如果他們的請求相同，我們需要將相同的配置文件ID返回給客戶端。

有什麼想法？

2011-11-18 TheGuest

命令不應該返回結果。

你可以做的是創建一個包含新配置文件的ID的命令，如果它是一個GUID。如果您使用某種種子標識列，當然這不起作用。

但是說你的ID是一個GUID。然後，您可以將命令中的GUID傳遞給後端。只有在GUID不存在的情況下，後端纔會創建新的配置文件 - 並且保證了唯一性。

2011-11-18 10:55:34

我們的命令確實沒有返回任何東西。所以你在說什麼，我們應該讓客戶端生成新的ID而不是API方法本身？這可能不是一個壞主意。 – TheGuest

這就是我所說的。如果您的ID是GUID，那麼它們來自何處並不重要，它們將是唯一的，並且您在添加行時不需要查詢數據庫以獲取ID。 –

對不起，也許我仍然在這裏錯過了一些東西....如果事件幾乎同時發生，以便在讀取模型中找不到配置文件，那麼您怎麼可能生成第二個guid來匹配域中現有的guid ？ – swannee

根據我對CQRS模式的理解，命令層不應該使用讀取模型來做出任何決定。命令層根據它自己的域來處理它。不是基於他閱讀模型。驗證始終在域數據上進行。您的profil創建命令處理程序應該檢查域中是否存在profil，而不是讀取模型中。

2011-11-24 11:39:03

-2

這是正確的。由於ReadModel的最終一致原則，命令不應該依賴ReadModel。

只需在命令中使用您的域根據它做出決定。

通常CQRS + EventSourcing存儲庫有很少的方法，但其中的GetById（Guid id）。你可以用它來檢查這個實體是否已經存在於域中。

2012-11-16 23:09:57

回答