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

　　圖10. PFM程序邊界上的反腐化層，防止在線銀行服務的變化影響到我們的邊界上下文

　　很明顯，一個外部系統需要一個獨立的上下文。然而對于一個已有的遺留組件，通常也伴有一個非常難以修改的模型。盡管遺留組件是在我們組織內部來維護的，甚至這個模型也會受到不同因素的影響，它會被其他的上下文所使用。如果必須和遺留系統進行交付，不同模型之間的轉換應該放在一個不同的界限上下文里。

　　上下文圖中還有其他的關系嗎?我們能夠根據相關的DDD模式對它們進行分類嗎?如果假設開發活動是在單一的團隊內進行的，那這里的模式就不會引起太多的關注。但是，如果“銀行”和“開銷”是由不同的團隊來維護的話，團隊之間應該是一種合作關系：他們的開發會朝向一個共同的目標(這里談論上游和下游沒有意義，因為他們處于同一級別)。如果Web用戶檔案模塊來自于外部，我們將會作為下游的上下文。

　　圖11. 加入了關系模式后的上下文圖

　　示例4：向組織擴展

　　到目前為止，我們只考慮了包含一個開發團隊的簡單場景。在這種場景下，我們可以忽略溝通的開銷，假設團隊中的每位開發者都很明確“模型將會如何發展”(也許有些樂觀)。更復雜的場景中還可能包含下面的影響因素：

　　領域復雜度(需要很多不同的領域專家)

　　組織復雜度

　　項目跨時很長

　　項目需要大量的人天

　　涉及到很多外部的、獨立的或者遺留的系統

　　大型團隊，多個開發組

　　分布的、離岸的團隊

　　個人因素

　　每個因素都會影響開發團隊和組織的通訊方式，并最終影響到要交付的軟件。

　　每個獨立的團隊，尤其是一個處在敏捷環境的團隊，團隊內的成員間有很多共享信息的方式：面對面的交談，多人參與的設計討論、結對編程、會議、信息散播裝置(information radiator)等等。但問題在于，當團隊規模、人數增加后，這些技術很難再繼續使用了，跨團隊地共享模型的概念完整性也非常困難。

　　畢竟，能夠對模型保持統一看法，是溝通中相當成熟的方式，這涉及到對問題具有一致的理解，以及對可行解決方案大致相似的看法。在那些溝通不順暢的場景下，“埋頭干”很容易取代了“識別和確認”。這種溝通瓶頸帶來的典型后果就是在同一個代碼庫中的不同地方散布著不同的類，它們做著基本上同樣的事情。

　　總有一天PFM應用會變得更大，這樣就要有另一個團隊(團隊B)和我們一起工作(顯然我們是團隊A)，他們開發一個名為“交易”的新模塊。團隊B可能在一個不同的房間、建筑物、城市、公司里，他們全心投入到新模塊的開發工作上。如下圖所示，團隊A與團隊B共享了一些代碼，雖然他們很可能會使用彼此獨立的代碼。最后，團隊B會寫一些類(比如圖12所示的A')來實現自己所需的功能，不過這些功能已經存在于類A了。

　　圖12. 當不同的團隊訪問相同的代碼庫時，他們會去關心模型上的不同部分。物理上的團隊分割會令信息共享的效果大打折扣

　　這是重復代碼，萬惡之源啊!在一個獨立的、良好定義的、有界的上下文內，這是毋庸置疑的。但是由于某些原因，這種現象幾乎會出現在所有復雜的項目中。這通常是個信號，告訴我們在項目的同一個區域內，或許存在沒有恰當隔離的上下文。不過在有些時候，使用兩個獨立的上下文是組織領域模型更加有效的手段，而不會強迫兩個不同的團隊不斷地去整合他們的模型。

　　那么，我們如何在圖上畫出這些呢?上下文圖反映了當前我們對整個系統的理解水平。一旦我們學到了更多東西，或者環境發生了改變，還會馬上更新它?，F在，我們還不能準確地預知接下來會發生什么，所以這就是“我們當前的理解水平”。

　　圖13. 尚未很好劃分的“交易”上下文，它還需要進一步探索或更切合實際的設計決策

　　圖中的危險警告符告訴我們那里有些問題：兩個上下文有局部的重疊，它們的關系還不是非常清晰。這可能是需要解決的第一類問題，可以嘗試著在上下文內設置一個被廣泛認可的、合理的關系，比如消費者-供應者、持續集成或者共享內核(Shared Kernel)。不過，這是明天的工作。上下文圖是為今天準備的工具，而問題在今天還存在著，所以我們還把警告符號留在圖中。

　　不要被圖中的顏色和陰影搞迷惑了。我不過是想讓上下文圖的打印效果更好一些。一個真實的上下文應該是很亂的，起碼和你的項目一樣亂。不過這個警告符提醒我們這里有一個危險區域，此處的上下文尚未被清晰地分離，事態很容易朝著“一團大泥球”發展(最有彈性的DDD組織模式)，除非我們采取行動。

　　一種非傳統觀點的視角

　　上下文圖迫使我們將非軟件的因素也包含在整體考慮中，這樣我們更能識別出一些污點熱區，而這些熱區在傳統架構分析的觀點中是“不在范圍內”的。

　　比如，組織內部的信息流通方式會在很大程度上影響最終的軟件。通常，在小型組織中，組件自身的用途是定義上下文邊界的主要因素，而在大型組織中，這個關鍵因素變成了溝通效率和項目組織方式。像Wiki、email或即時消息軟件會給我們一種假象——團隊中每位成員的知識都不斷地保持著同步。但是我們都知道這只是個夢想罷了：在一個典型的大型項目中，我們不是Borg人(譯注：源自《星際旅行》中的外星生物，所有Borg人的思想是互聯的，可以完全共享知識)那樣的智能聯合體，很多人對于自己團隊以外的情況知之甚少。

　　在大型組織中定義上下文邊界是一項頗具挑戰的任務，但回報卻也相當豐厚。很多時候，各個團隊并不清楚多個模型存在的事實;之所以概念的完整性會頻遭破壞，是因為只有很少人或者沒有人看到完整的圖景。繪制上下文圖是一個不斷探索的過程，很多部分的內容在首次嘗試時都是不正確的，邊界在初期也是很模糊的，還需要很長的路要走，才能獲得一個更清晰的完整圖景。

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