如何解決Order和Warehouse有界上下文依賴關係？

Question

我正在致力於DDD項目，我目前主要關注兩個受損的環境，訂單和倉庫。

令我困惑的是以下情況： 訂單跟蹤所有下訂單，倉庫跟蹤所有可用庫存。如果用戶對某個產品項目下了一個訂單，這意味着倉庫中該產品的一個更少的項目。我簡單地說明了這一過程，所以請耐心等待。

由於兩個領域模型被放置在不同的BC內，我目前依靠最終的一致性即。在一件物品被出售之後，它最終會從倉庫中移出。

不幸的是，這種情況導致了另一個用戶可能同時進行同一項目的另一個訂單的問題場景，並且它會顯示爲可用，直到最終的一致性踢球爲止。這是領域專家無法接受的。

所以IMO我堅持兩個選項

• 合併訂單和庫存（至少部分有關產品 庫存，倉庫可用單位）爲BC一個
• 有秩序BC（或微服務，如果您希望）取決於倉庫BC（微服務）以便拉動現有產品單元 可用

哪個選項確實跟隨DDD模板？有另一種出路嗎？

Answer 1

您可以使用超時預訂系統。

使用消息的比喻：隨着券商風格排隊機制（如RabbitMQ的）你從隊列中的消息，你擁有控制權，直到您承認，它可以從隊列或者你被移除版本它回到隊列。

您可以在訂購過程中做同樣的事情。您保留訂單上的任何物品。所以當你添加他們時，他們的狀態是reserving，並且發送一些消息來保留這些項目。如果回覆返回，您可以決定如何繼續。也許你可以添加任何不能保留的項目，或稍後再試。

將會有不同的方法來解決這個問題。根據您的業務案例，它可能是可以接受的只有當有人真的接受訂單時檢查可用性。

如果你的領域專家認爲它是完全不能接受的是，在過程結束時解決這個問題，那麼你可以將它移動到開始。問題當然是用戶A可以保留並永不購買，從而使用戶B失去作爲客戶;而在流程結束時僅應用該項目的「獲取」項目更接近於確保購買。但這是一個商業決定。

Answer 2

這個問題是一個非常好的例子，其實際情況最終是一致的。如果倉庫中沒有庫存 - 即使在接下來的20分鐘內有補貨，是否真的是拒絕訂單的最佳選擇？

如果物品實際在貨架上，但操作員尚未將其鍵入系統中，該怎麼辦？

有時候，設計師和領域專家認爲人們希望100％一致，當真的，用戶可能願意接受延遲確認他們的訂單，如果它增加了他們的訂單被接受而不是被拒絕的機會。

在上述情況下，爲什麼使用戶的工作在N分鐘後重試其訂單？在最終一致的系統中，您可以通過包含超時重試嘗試在一段時間內完成訂單來適應這種時間靈活性，然後再確認客戶端確實無法完成訂單。

有技術解決方案可以讓你百分百的一致性，但我認爲這不是一個技術挑戰，而是一種文化/思維方式的挑戰，改變人們對於什麼可能是可以接受的想法&實際上是一個更好的結果。