DDD：除了電子商務示例之外，如何將應用程序劃分爲有界的上下文？

Question

我們在這裏有一個非常大的應用程序，我考慮按照DDD傢伙的指導重構一下它。

現在，它的頭號問題是有界上下文和上下文映射。也許我只是不喜歡它，但在我看來，根本不可能做分工。例如，我們在所有地方都有User對象，它與User對象完全相同：顯示名稱，ID和角色。還有另外一個例子：我們有了CatalogItem對象來幫助我們對整個地方的另一個實體進行分類。我們是否必須引入有界上下文依賴關係？除了那個令人討厭的電子商務樣本之外，對這個問題還有任何指導嗎？

Answer 1

我發現，起初，有界的上下文和聚合根似乎是DDD中最簡單的概念。直到你真正開始實施DDD應用程序並帶來真實世界的問題。這裏沒有簡單的答案。這完全取決於您的業務需求（可擴展性，可用性，延遲，一致性等）。 「正確」的解決方案是平衡這些問題以最好地滿足您的需求的解決方案。

隨着你給的例子中，有幾個選擇：

• 一個大界上下文
• 獨立的限界上下文，隨着重複數據
• （可能使用發佈/訂閱消息系統中實現）將用戶和目錄項拉入它們自己的有界上下文中，並讓其他有界上下文通過服務訪問它們

有一點需要記住的是queryi 「寫作」需求通常與需求大不相同。它通常可以簡化您的應用程序設計，使其單獨有界上下文純粹用於查詢。如果這聽起來可能適用，請查看CQRS。