有界上下文找到邊界？

Question

在我目前的項目（電子商務網站）中，我們有不同的有限上下文，如結算，交付或付款在我們的結帳過程。

最重要的是，根據客戶的購買意願，結帳過程將有所不同。因此，根據購物車的內容，結帳過程中的步驟數可能會有所不同，或者我們不會/會要求她提供某些信息。

那麼應該爲每種不同類型的結帳過程創建不同的有界上下文嗎？

例如，訂單總根將根據結帳過程 EticketsOrder（在這種情況下，所以我們不會要求一個用戶，我們不需要送貨地址） 票務BillingAddress

不同

ClothesOrder（在這種情況下，我們需要一個送貨地址，會出現在結賬過程中的額外的步驟可以解決） 衣服BillingAddress是DeliveryAddress

這種分離意味着要建立兩個不同的領域實體甚至認爲它們具有類似的特性。

模擬這類問題的最佳方法是什麼？如何找到上下文邊界？

Answer 1

看起來好像您可能錯過了有界的上下文。當發生這種情況時，往往會嘗試將功能融入現有的BC中。聚合根源也是一樣。如果某些東西看起來笨拙或者沒有意義，試着看看你是否沒有錯過任何東西。

在你的例子中，我會建議購物BC（或任何有意義的名稱）。您正嘗試將您的結帳流程納入您的訂單BC。您的購物BC將負責收集所有數據，然後將其穿梭到相關部分。

所選產品類型將決定是否需要實物交貨。

希望有所幫助。

Answer 2

有界環境主要是語言邊界。從藍皮書引號（高亮按鍵部分）：

一個限界上下文劃所以 團隊成員有什麼有 是一致的，以及如何明確和共同的理解特定模型的適用性它涉及到其他的上下文。在該範圍內，努力保持模型在邏輯上統一，但不要擔心 關於在這些範圍之外的適用性。在其他上下文中，其他 模型適用，術語不同，概念和規則， 和通用語言的方言。

要問的一個問題是，創建的不同類型的訂單是完全不同的集合，還是它們都訂購具有不同值的集合。是否需要整體考慮訂單，而不管它們是如何創建的？我已經建立並使用了電子商務系統，其中不同類型的訂單都被建模爲相同彙總的實例，只是具有不同的設置，並且沒有語言問題。另一方面，您的域中的訂單可能會有所不同，以保證不同的上下文。

我經常從functional cohesion的角度考慮BC界限。如果將訂單分成兩個BC，它們之間是否存在高度的耦合？如果是這樣，那可能是一個跡象表明它們應該合併成一個BC。另一方面，如果不列顛哥倫比亞省僅與報告目的相互作用的地方，則不需要將它們合併。