軟件開發項目中的關鍵決策:基于上下文圖的策略性領域驅動開發(4)

　　圖14. 上下文圖的最新版本。不要指望它是“最終”的，我們總是會學到一些新的東西。

　　涉及到的上下文還可能更多，比如“交易”模塊可能需要鏈接到一些在線股票價格服務，但這是交易模塊的事!這個上下文圖是關于我們(團隊A)的，我們的工作內容是“銀行”和“開銷跟蹤”模塊：我們只對直接關聯的、會影響到自身軟件的那些上下文感興趣。

　　一旦我們收集到更多的信息，上下文圖就會變得更加清晰。正如前面提到的，只要認識到應用程序中存在著各種不同的模型，而且這些模型的完整性可以在一個良好定義的有界上下文中得以保存，這會為我們的領域建模的視角提供諸多益處。很多模型都在成長的過程中逐漸失去完整性，上下文圖會在這個方面給予我們很多幫助。

　　談談策略性DDD模式

　　此處我們使用模式的方式略有不同：盡管定義是一樣的——為一類反復出現的問題提供解決方案——但這些模式很少能展現出可供我們選擇的解決方案。更可能的場景是，組織架構會決定模式，我們惟一的希望就是在事態走到死胡同以前識別出它們。有些時候我們有機會選擇最好的選項，或者改變現有的狀況，但是我們必須清楚的是，在組織級別的改變所需的時間可能已經遠遠超過了項目持續的時間，或者這個改變根本就是不可能的。

　　如果你還在猶豫應該從那里開始，那么就從開發團隊開始吧。對于有效地共享模型信息來說，一個團隊應該是最大的組織單元。當識別出多個上下文后，可以由一個團隊管理它們，這樣很大程度上將問題歸結為架構的抉擇。

　　每一種模式都有不同的開銷：即使它們解決的是類似的問題(相近的上下文)，也不能簡單地交換。比如，反腐化層會在代碼層面(一個額外層)上留下痕跡，并在組織里留下很小的痕跡。盡管Partnership或者“客戶-供應者”模式可能需要更少的代碼和一個單獨的代碼庫，但是如果沒有有效的溝通渠道和良好的過程的話，也很難應用起來。企圖在沒有合作的環境下安排執行Partnership模式，無異于自尋死路。

　　結論

　　讓我們在回到“上下文”最初的定義上來——“一個單詞或一個句子所出現的環境，這個環境會反過來影響它們的含義”——它非常準確，而且可以應用在設計層面、架構層面乃至組織層面上，卻沒有損失其準確性和有效性。盡管有些“對統一性的期望”是合情合理的，但是模型不能被無限地擴張。界限上下文提供了一種非常安全的機制，它允許模型在其內部不斷變得復雜，同時又不犧牲概念的完整性。

　　當把上下文圖應用到大型的項目上后，它還可以顯示出當前組織內的隱式邊界，并提供一個來自第一手的、沒有PS過的項目境況的快照。一個好的上下文圖能讓你看到所面對的不利條件的大致狀況?？赡苣阋呀浿?mdash;—但通常都是不知道——組織是否在扮演項目成功的絆腳石，即使項目還沒有開始。

　　作為一名顧問，我發現上下文圖能夠奇跡般地讓我快速獲取客戶項目的細節。上下文圖還充當了策略決策的支持工具(畢竟，這是“圖”的本意)。上下文圖提供了系統的全局視圖，幫助我們關注在選擇那些能在你的環境中真正可行的方案，而不是把錢浪費在對系統不切實際的構想中，這是UML或者架構圖所做不到的。

　　關于作者

　　Alberto是來自Avanscoperta的一名咨詢顧問和培訓師。他致力于幫助客戶管理軟件開發的復雜度。他堅信只有那種全盤考慮的軟件開發方法才能開發出有用的軟件。

原文轉自：http://www.kjueaiud.com