在社會技術系統中調整有界上下文，以支援業務價值流。當您能夠了解業務的價值流時，請在DDD戰略層面上使用它們。

例如，在一家線上銷售實物商品的電子商務公司中，體現業務價值流的活動包括：

• （根據物理位置或從遠端）獲取要出售的物品
• 描述其物理細節（顏色，質量，圖片和其他有助於其投放市場的資訊）
• 評估和互動以處理庫存數量
• 為客戶建立和管理機制，以瀏覽目錄，下訂單和付款，排程專案

同時，有一個營銷系統來放置廣告，完成銷售後，將有一些客戶服務功能。

以上所有都是價值流的活動。它們可以並行發生，並且流可能有些複雜，但是它們可以彼此獨立進行。但是，它們具有依賴性。例如，負責讓客戶下訂單的系統顯然需要了解可用物品的庫存-它們是相互關聯的。

上下文語境

“如果無法描述您在一個流程中正在做什麼，那麼您將不知道自己在做什麼。” -威廉·愛德華茲·戴明

關於價值流和價值流對映的文獻很多，但是我認為要理解的關鍵概念並沒有得到更多的詳細說明。從這個角度來看，精益價值流的概念是組織為了為客戶，利益相關者或終端使用者產生總體結果而進行的一系列活動的示意圖。流程的活動是獨立的，但相互聯絡；這是複雜系統的特性之一。每個活動在自治中執行不同的任務，但會將資訊反饋給系統的其他部分，以使價值鏈進入下一階段。

為了使組織的整體熵得到控制，企業必須正確地將這些活動分離並分組為獨立但相互關聯的子系統，並優化其通訊。這是關鍵點。在領域驅動設計的世界中，這些子系統稱為“ 有界上下文”。

由於有界上下文是高階模組，因此它們之間還應該特別關注通訊。此外，鑑於要達成良好的理解，我們應該將焦點移至外部系統（如羅素·阿科夫（Russell Ackoff）所述），這解釋了為什麼理解價值流以在有界上下文之間設計最佳互動流很重要。 

系統的這種邏輯、高階檢視比內部結構更重要，因為它是做正確的事情的關鍵。在這裡，關鍵是要在它們的獨立性和相互關係之間找到完美的平衡，並決定如何分割它們。應該將哪些子任務組合在一起以形成一個有界的上下文，那麼什麼標準衡量應該獨立存在呢？

答案是，這取決於整體情況–抱歉，這裡也沒有靈丹妙藥！但是我們有一些原則可以幫助您進行決策的歸納過程。例如，我們可以在此處看到與凝聚力和耦合力相同的作用力：

• 凝聚力太強：將每個任務都放在一個大範圍的上下文中將意味著糾結系統，使其難以更改和擴充套件，類似於上帝和發散性需要更改程式碼的壞味道。
• 耦合過多：將每個任務拆分為自己的有界上下文意味著將複雜性移到它們之間的通訊上，從而產生大量依賴關係。此外，實現獨立性的方法在SOA環境中並非免費的。必須建立，部署，維護和監視基礎結構邊界。

“您必須選擇在哪裡支付複雜性的代價。因為DDD旨在降低軟體的複雜性，所以結果是您要為維護重複的模型和可能的重複資料付出代價。” -埃裡克·埃文斯（Eric Evans）