英文原文：Strategic Domain Driven Design with Context Mapping

　　作者：Alberto Brandolini 譯者：韓鍇 發(fā)布于 2010年4月6日

　　簡介

　　當(dāng)應(yīng)用程序逐漸變得龐大和復(fù)雜后，很多面向?qū)ο蠼５姆椒ǘ歼_(dá)不到非常好的可伸縮性。上下文圖（Context Mapping）是一種通用目的的技術(shù)，作為領(lǐng)域驅(qū)動(dòng)開發(fā)大家族的一名成員，它幫助架構(gòu)師和開發(fā)人員管理他們在軟件開發(fā)項(xiàng)目中不得不面對的形形色色的復(fù)雜性。與其他廣為人知的DDD模式相比，上下文圖可以應(yīng)用在任何軟件開發(fā)的場景中，在開發(fā)者進(jìn)行策略性決策時(shí)，為他們提供一個(gè)高層視圖，比如是采用全套的DDD實(shí)現(xiàn)，還是根據(jù)項(xiàng)目的特定條件進(jìn)行取舍等。

　　在這篇文章中，我們將探討界限上下文，以及如何在構(gòu)建上下文圖時(shí)應(yīng)用它們，來支持軟件開發(fā)項(xiàng)目中的關(guān)鍵決策。

　　多個(gè)模型共存

　　領(lǐng)域驅(qū)動(dòng)開發(fā)花了很大力氣強(qiáng)調(diào)一件事，即維護(hù)應(yīng)用程序模型的概念完整性。要做到這一點(diǎn)，需要很多因素：

• 一種敏捷的流程，確保能從用戶和領(lǐng)域?qū)＜夷抢镱l繁地獲得反饋，
• 確保有若干領(lǐng)域?qū)＜以趫觯⑶遗c他們開展創(chuàng)造性的合作，
• （在應(yīng)用和測試代碼中）維護(hù)單一的、可共享的模型，并用通用語言精確地進(jìn)行定義它，
• 營造一種開放透明的環(huán)境，鼓勵(lì)學(xué)習(xí)與探索。

　　這些對于營造一個(gè)可以讓高質(zhì)量的設(shè)計(jì)繁榮發(fā)展的環(huán)境至關(guān)重要。即使是這樣的環(huán)境，那些常見的DDD元素，比如實(shí)體、值對象、聚合，也會(huì)逐漸地形成一個(gè)復(fù)雜領(lǐng)域模型。所以，如果不對模型的概念完整性進(jìn)行妥協(xié)的話，傳統(tǒng)的DDD方法也不能盲目地應(yīng)用在一個(gè)無限大的領(lǐng)域模型中。

　　如圖1所示，在DDD中，通用語言的關(guān)鍵責(zé)任是對模型進(jìn)行完整性檢查。無論是與領(lǐng)域?qū)＜业挠懻摚€是最終的實(shí)現(xiàn)代碼，都可以通過使用相同的術(shù)語，并將領(lǐng)域知識清晰準(zhǔn)確地進(jìn)行定義，以此來保證團(tuán)隊(duì)中的每位成員可以分享都相同的領(lǐng)域知識和軟件。

　　圖1. 通用語言應(yīng)該是用于表達(dá)模型的唯一語言。團(tuán)隊(duì)中的每位成員應(yīng)該對每個(gè)特定術(shù)語達(dá)成一致。這些術(shù)語不能有歧義，也不允許在不同角色間進(jìn)行翻譯。

　　代碼是表達(dá)模型的主要形式。雖然其他一些工件或許也能捕獲需求或者局部設(shè)計(jì)，但是只有代碼自身才會(huì)與應(yīng)用程序的行為永遠(yuǎn)保持一致。不過這種看上去美妙的建模方式其實(shí)非常脆弱：如果滿足了前面提到的四條要求，它能做到，但是不能被無限地?cái)U(kuò)展。真正讓模型得以最大程度地?cái)U(kuò)展，并且不必犧牲其概念完整性的方法叫做“上下文”。

　　了解“界限上下文”

　　在領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的世界里，“上下文”是這樣定義的：

　　“一個(gè)單詞或一個(gè)句子所出現(xiàn)的環(huán)境，這個(gè)環(huán)境會(huì)反過來影響它們的含義。”

　　這段定義初看起來相當(dāng)含糊。它并沒有直接告訴我們“上下文”的大小、形狀或者其他什么特性。但是最后我們又發(fā)現(xiàn)這個(gè)定義其實(shí)非常準(zhǔn)確地描述了“上下文”是什么，如果要想窺得其全貌的話，大概還需要一些具體的例子。

　　示例1：術(shù)語相同，含義不同

　　第一個(gè)例子很簡單，它示范了在術(shù)語層面出現(xiàn)歧義的情況。有些詞匯根據(jù)不同的使用場景，會(huì)有不同的含義。

　　假設(shè)我們正在開發(fā)一個(gè)基于Web的個(gè)人金融管理程序（PFM）。該程序可能用于管理銀行帳戶（Account）、股票、儲(chǔ)蓄，未來可能用于追蹤預(yù)算和開銷記錄等等。

　　在這個(gè)程序中，領(lǐng)域術(shù)語“帳戶”可能是指不同的概念。談?wù)撱y行的時(shí)候，一個(gè)“帳戶”在邏輯上其實(shí)是“金錢的容器”；于是我們自然而然地為相應(yīng)的類加上“余額”、“帳戶號”等屬性。但是，在“Web應(yīng)用程序”的上下文中，術(shù)語“帳戶”會(huì)有非常不同的含義，它和用戶的認(rèn)證、可信度有關(guān)。如圖2所示，相應(yīng)的模型將是完全不同的。

　　圖2. 一個(gè)出現(xiàn)歧義的簡單場景：當(dāng)術(shù)語“帳戶”應(yīng)用在不同的上下文時(shí)，它的含義可以是完全不同的。

　　這應(yīng)該是我們在對應(yīng)用程序建模的時(shí)候，所遇到的最簡單的歧義場景了：一個(gè)術(shù)語，有兩個(gè)與上下文相關(guān)的含義。這個(gè)問題的解決辦法通常是在類的全名（類名或者包名）前面加一些前綴，以此來劃分名字空間。但是在概念層面上，必須清楚我們在和兩個(gè)上下文打交道，有時(shí)不同上下文之間的區(qū)別很大，足以防止開發(fā)人員犯錯(cuò)誤，但有時(shí)這樣的區(qū)別卻非常微妙。

　　不過，在類名層面上解決問題的方式并不能用在所有的情況下：在銀行的領(lǐng)域里，術(shù)語“銀行帳戶”或許已經(jīng)存在了，但卻有不同的含義；或者領(lǐng)域?qū)＜覉?jiān)持使用“帳戶”作為術(shù)語。此時(shí)切記不要發(fā)明一個(gè)特殊的兩頭折衷的術(shù)語，或者在專家術(shù)語和代碼之間引入一個(gè)“翻譯層”。否則你將不得不面對兩個(gè)獨(dú)立的上下文。

　　繪制第一份上下文圖

　　當(dāng)歧義真的到來的時(shí)候，我們需要一種工具來讓開發(fā)團(tuán)隊(duì)明白，應(yīng)用程序中正存在著兩個(gè)不同的上下文。“歧義”是通用語言的頭號大敵，我們必須鏟除它。消除歧義的最好辦法就是在上下文圖中，將領(lǐng)域結(jié)構(gòu)分拆在多個(gè)界限上下文中。

　　圖3. 包含兩個(gè)領(lǐng)域上下文的上下文圖

　　按照領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)一書的描述，上下文圖是用于將上下文邊界變得更清晰的重要工具。其基本的想法是在白板上畫出上下文的邊界，然后選擇性地將相關(guān)類的領(lǐng)域術(shù)語填寫在上面。它不是一幅繪制精美的UML圖：它是一個(gè)可用的工具，允許我們描繪那種模糊不清的狀況，因此它自身看上去模糊不清也就不足為其了。

　　示例2：概念相同，用法不同

　　還有一種更加令人困惑的情況，就是底層的概念相同，但是使用的方式不同，最終導(dǎo)致了不同的模型。銀行帳戶的模型是一個(gè)BankingAccount類，如圖4所示。

　　圖4. 精簡版本的BankingAccount類

　　通常，有些PFM應(yīng)用也允許我們管理支付行為，并且持有一個(gè)收款人（Payee）注冊器。在這個(gè)場景中，收款人可能與一個(gè)或者多個(gè)銀行帳戶關(guān)聯(lián)，但是對于收款人來說，我們既不能獲取其銀行帳戶的內(nèi)部情況，也不能在該帳戶上觸發(fā)任何操作。那么將“收款人帳戶”與剛剛定義的BookingAccount類關(guān)聯(lián)在一起是否正確呢？

　　圖5. Payee類與BankingAccount類

　　恩......這聽上去有些道理：畢竟它們都是相同的概念，在現(xiàn)實(shí)世界中，我們的帳戶和收款人的帳戶甚至?xí)幵谕粋€(gè)物理上的銀行里。另一方面，這樣做似乎又不完全正確：因?yàn)槲覀儾辉试S調(diào)用收款人銀行帳戶的任何操作，也不能追蹤他們的任何信息。更糟的是，這樣做了后，可能會(huì)在我們的程序中埋下一個(gè)概念的錯(cuò)誤。

　　我們應(yīng)該如何做？我們應(yīng)該再一次回到應(yīng)用程序的兩個(gè)不同的上下文里去：這一次我們可以采取兩種不同的方式對同一個(gè)領(lǐng)域概念進(jìn)行建模，因?yàn)閷︻I(lǐng)域概念的兩種使用場景明顯不同，每一種都需要一個(gè)不同的模型。BankingAccount類仍然允許我們執(zhí)行（或者跟蹤）特定的操作（比如存款與取款），同時(shí)另一個(gè)獨(dú)立的PayeeAccount類可能有一些和BankingAccount相同的通用數(shù)據(jù)（比如accountNumber），但是有一個(gè)簡化的模型和完全不同的行為（比如我們不能訪問收款人的余額信息）。圖6所示的正是這種場景：盡管“銀行帳戶”有著清晰的含義，其底層概念也是惟一的，但是在應(yīng)用程序中卻以不同的方式被使用著。

　　圖6. BankingAccount和PayeeAccount類

　　這看著似乎挺明顯的，其實(shí)不然。當(dāng)你設(shè)計(jì)類圖，或者使用UML建模工具時(shí)，你可能很自然地讓收款人具有一個(gè)bankingAccount屬性，而且會(huì)慶幸“我剛好有一個(gè)這樣的類”。Pavlovian試圖去除代碼中的重復(fù)，有時(shí)，它的作用會(huì)弊大于利。

　　如圖7所示的上下文圖，可以用于表述上面討論的示例。注意，只要我們關(guān)于環(huán)境的知識在增加，就將它反映在圖中。在這個(gè)例子中，我們將PFM的應(yīng)用上下文分成了“銀行”和“開銷跟蹤”。

　　圖7. 非常簡單的上下文圖：畫上了領(lǐng)域模型區(qū)域間的輪廓，可以看出在這些區(qū)域內(nèi)保證了概念的完整性

　　在這個(gè)例子中，兩個(gè)上下文擁有一些邏輯上重疊的區(qū)域，即“銀行帳戶”的概念，它在應(yīng)用程序的不用區(qū)域中，使用方式也不同，這意味著我們要使用不同的模型。但是兩個(gè)模型又可能有非常緊密的交互。上下文圖除了能幫助我們保證模型的概念在不同上下文邊界內(nèi)的完整性，它還能幫助我們關(guān)注在不同上下文之間出現(xiàn)的情況。在這個(gè)例子中，假設(shè)同一個(gè)團(tuán)隊(duì)正在兩個(gè)上下文上同時(shí)工作，我們就需要讓團(tuán)隊(duì)中的每位成員的明確兩個(gè)上下文的區(qū)別，并且就兩個(gè)上下文中出現(xiàn)的術(shù)語和概念，分享同一個(gè)轉(zhuǎn)換的映射關(guān)系。

　　示例3：外部系統(tǒng)

　　再來考慮一下PFM。很多這種應(yīng)用程序都需要與某些金融在線服務(wù)進(jìn)行數(shù)據(jù)交換。在這個(gè)例子中，銀行會(huì)為家庭銀行服務(wù)提供實(shí)時(shí)的訪問。其他的例子還包括允許用戶下載通用標(biāo)準(zhǔn)格式（比如Money或者Quicken格式）的銀行對帳單。但是從上下文圖的視角來看，無論是交互活動(dòng)還是通訊的方向（單向或是雙向），并不重要。有一件事是要關(guān)注的，我們有了不同的模型。圖8展示了PFM與在線銀行應(yīng)用程序的交互行為。

　　圖8. 在上下文圖中，與外部應(yīng)用的交互行為很自然地需要獨(dú)立的界限上下文

　　即使設(shè)計(jì)兩個(gè)模型之初是讓它們展現(xiàn)相同的數(shù)據(jù)（至少在一定程度上），但隨著時(shí)間的推移，它們還是會(huì)受到不同因素的影響，而且它們也會(huì)用于不同的目的。因此，分離上下文邊界是必須的。如果假設(shè)用戶檔案（User profiling）模塊是由第三方庫實(shí)現(xiàn)的，那么示例1也能夠歸入到這一類中。

　　管理多個(gè)上下文

　　當(dāng)應(yīng)用程序跨越了多個(gè)上下文后，我們必須管理上下文之間的關(guān)聯(lián)。不同的界限上下文之間的關(guān)系，通常是我們深入觀察項(xiàng)目的線索。

　　有一件事情非常關(guān)鍵，即兩個(gè)上下文之間的聯(lián)系是有方向的。DDD用兩個(gè)專門的術(shù)語表述它們：“上游（upstream）”和“下游（downstream）”，一個(gè)上游上下文會(huì)影響到相應(yīng)的下游上下文，但是反過來就不一定了。這不僅體現(xiàn)在代碼上（一個(gè)庫依賴于另一個(gè)），還體現(xiàn)在技術(shù)含義較少的因素上，比如進(jìn)度、對外部請求的響應(yīng)，比如，當(dāng)在線銀行服務(wù)更改了API或者其他什么原因，我們的PFM銀行應(yīng)用程序都必須要快速地更新。所以我們的PFM上下文應(yīng)該是下游的，而在線銀行服務(wù)很明顯就是上游的了。圖9演示了這兩種領(lǐng)域上下文的關(guān)系。

　　圖9. 分離的上下文之間的Upstream-downstream關(guān)系

　　如果外部系統(tǒng)發(fā)生變化，我們可以接受這種變化，來更新與外部系統(tǒng)通訊的方式。不過我們?nèi)匀恍枰恍┍Ｗo(hù)措施隔離來自上游上下文的變化，保證我們自己的“銀行”的上下文的概念完整性。DDD包含了幾種組織模式，幫助我們描述和管理不同的上下文交互方式。最適合我們在這里使用的是模式叫做反腐化層（Anti-Corruption Layer，ACL），它會(huì)在代碼層面上實(shí)現(xiàn)顯式的轉(zhuǎn)換，轉(zhuǎn)換可以在兩個(gè)上下文之間，或者在“銀行”上下文的外部邊界上完成。這不僅局限于技術(shù)上的轉(zhuǎn)換，比如Java轉(zhuǎn)化為XML，同時(shí)也是一個(gè)很合適的機(jī)會(huì)，能夠管理各個(gè)模型之間的所有微妙的不同。如下面的圖10所示，我們在上下文圖上添加了ACL。

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

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

　　上下文圖中還有其他的關(guān)系嗎？我們能夠根據(jù)相關(guān)的DDD模式對它們進(jìn)行分類嗎？如果假設(shè)開發(fā)活動(dòng)是在單一的團(tuán)隊(duì)內(nèi)進(jìn)行的，那這里的模式就不會(huì)引起太多的關(guān)注。但是，如果“銀行”和“開銷”是由不同的團(tuán)隊(duì)來維護(hù)的話，團(tuán)隊(duì)之間應(yīng)該是一種合作關(guān)系：他們的開發(fā)會(huì)朝向一個(gè)共同的目標(biāo)（這里談?wù)撋嫌魏拖掠螞]有意義，因?yàn)樗麄兲幱谕患墑e）。如果Web用戶檔案模塊來自于外部，我們將會(huì)作為下游的上下文。

　　圖11. 加入了關(guān)系模式后的上下文圖

　　示例4：向組織擴(kuò)展

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

• 領(lǐng)域復(fù)雜度（需要很多不同的領(lǐng)域?qū)＜遥?/li>
• 組織復(fù)雜度
• 項(xiàng)目跨時(shí)很長
• 項(xiàng)目需要大量的人天
• 涉及到很多外部的、獨(dú)立的或者遺留的系統(tǒng)
• 大型團(tuán)隊(duì)，多個(gè)開發(fā)組
• 分布的、離岸的團(tuán)隊(duì)
• 個(gè)人因素

　　每個(gè)因素都會(huì)影響開發(fā)團(tuán)隊(duì)和組織的通訊方式，并最終影響到要交付的軟件。

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

　　畢竟，能夠?qū)δＰ捅３纸y(tǒng)一看法，是溝通中相當(dāng)成熟的方式，這涉及到對問題具有一致的理解，以及對可行解決方案大致相似的看法。在那些溝通不順暢的場景下，“埋頭干”很容易取代了“識別和確認(rèn)”。這種溝通瓶頸帶來的典型后果就是在同一個(gè)代碼庫中的不同地方散布著不同的類，它們做著基本上同樣的事情。

　　總有一天PFM應(yīng)用會(huì)變得更大，這樣就要有另一個(gè)團(tuán)隊(duì)（團(tuán)隊(duì)B）和我們一起工作（顯然我們是團(tuán)隊(duì)A），他們開發(fā)一個(gè)名為“交易”的新模塊。團(tuán)隊(duì)B可能在一個(gè)不同的房間、建筑物、城市、公司里，他們?nèi)耐度氲叫履K的開發(fā)工作上。如下圖所示，團(tuán)隊(duì)A與團(tuán)隊(duì)B共享了一些代碼，雖然他們很可能會(huì)使用彼此獨(dú)立的代碼。最后，團(tuán)隊(duì)B會(huì)寫一些類（比如圖12所示的A'）來實(shí)現(xiàn)自己所需的功能，不過這些功能已經(jīng)存在于類A了。

　　圖12. 當(dāng)不同的團(tuán)隊(duì)訪問相同的代碼庫時(shí)，他們會(huì)去關(guān)心模型上的不同部分。物理上的團(tuán)隊(duì)分割會(huì)令信息共享的效果大打折扣

　　這是重復(fù)代碼，萬惡之源啊！在一個(gè)獨(dú)立的、良好定義的、有界的上下文內(nèi)，這是毋庸置疑的。但是由于某些原因，這種現(xiàn)象幾乎會(huì)出現(xiàn)在所有復(fù)雜的項(xiàng)目中。這通常是個(gè)信號，告訴我們在項(xiàng)目的同一個(gè)區(qū)域內(nèi)，或許存在沒有恰當(dāng)隔離的上下文。不過在有些時(shí)候，使用兩個(gè)獨(dú)立的上下文是組織領(lǐng)域模型更加有效的手段，而不會(huì)強(qiáng)迫兩個(gè)不同的團(tuán)隊(duì)不斷地去整合他們的模型。

　　那么，我們?nèi)绾卧趫D上畫出這些呢？上下文圖反映了當(dāng)前我們對整個(gè)系統(tǒng)的理解水平。一旦我們學(xué)到了更多東西，或者環(huán)境發(fā)生了改變，還會(huì)馬上更新它。現(xiàn)在，我們還不能準(zhǔn)確地預(yù)知接下來會(huì)發(fā)生什么，所以這就是“我們當(dāng)前的理解水平”。

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

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

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

　　一種非傳統(tǒng)觀點(diǎn)的視角

　　上下文圖迫使我們將非軟件的因素也包含在整體考慮中，這樣我們更能識別出一些污點(diǎn)熱區(qū)，而這些熱區(qū)在傳統(tǒng)架構(gòu)分析的觀點(diǎn)中是“不在范圍內(nèi)”的。

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

　　在大型組織中定義上下文邊界是一項(xiàng)頗具挑戰(zhàn)的任務(wù)，但回報(bào)卻也相當(dāng)豐厚。很多時(shí)候，各個(gè)團(tuán)隊(duì)并不清楚多個(gè)模型存在的事實(shí)；之所以概念的完整性會(huì)頻遭破壞，是因?yàn)橹挥泻苌偃嘶蛘邲]有人看到完整的圖景。繪制上下文圖是一個(gè)不斷探索的過程，很多部分的內(nèi)容在首次嘗試時(shí)都是不正確的，邊界在初期也是很模糊的，還需要很長的路要走，才能獲得一個(gè)更清晰的完整圖景。

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

　　涉及到的上下文還可能更多，比如“交易”模塊可能需要鏈接到一些在線股票價(jià)格服務(wù)，但這是交易模塊的事！這個(gè)上下文圖是關(guān)于我們（團(tuán)隊(duì)A）的，我們的工作內(nèi)容是“銀行”和“開銷跟蹤”模塊：我們只對直接關(guān)聯(lián)的、會(huì)影響到自身軟件的那些上下文感興趣。

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

　　談?wù)劜呗孕訢DD模式

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

　　如果你還在猶豫應(yīng)該從那里開始，那么就從開發(fā)團(tuán)隊(duì)開始吧。對于有效地共享模型信息來說，一個(gè)團(tuán)隊(duì)?wèi)?yīng)該是最大的組織單元。當(dāng)識別出多個(gè)上下文后，可以由一個(gè)團(tuán)隊(duì)管理它們，這樣很大程度上將問題歸結(jié)為架構(gòu)的抉擇。

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

　　結(jié)論

　　讓我們在回到“上下文”最初的定義上來——“一個(gè)單詞或一個(gè)句子所出現(xiàn)的環(huán)境，這個(gè)環(huán)境會(huì)反過來影響它們的含義”——它非常準(zhǔn)確，而且可以應(yīng)用在設(shè)計(jì)層面、架構(gòu)層面乃至組織層面上，卻沒有損失其準(zhǔn)確性和有效性。盡管有些“對統(tǒng)一性的期望”是合情合理的，但是模型不能被無限地?cái)U(kuò)張。界限上下文提供了一種非常安全的機(jī)制，它允許模型在其內(nèi)部不斷變得復(fù)雜，同時(shí)又不犧牲概念的完整性。

　　當(dāng)把上下文圖應(yīng)用到大型的項(xiàng)目上后，它還可以顯示出當(dāng)前組織內(nèi)的隱式邊界，并提供一個(gè)來自第一手的、沒有PS過的項(xiàng)目境況的快照。一個(gè)好的上下文圖能讓你看到所面對的不利條件的大致狀況。可能你已經(jīng)知道——但通常都是不知道——組織是否在扮演項(xiàng)目成功的絆腳石，即使項(xiàng)目還沒有開始。

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

　　關(guān)于作者

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

　　英文原文：Strategic Domain Driven Design with Context Mapping

it知識庫：基于上下文圖的策略性領(lǐng)域驅(qū)動(dòng)開發(fā)，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時(shí)間聯(lián)系我們修改或刪除，多謝。