英文原文：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ū)動開發(fā)大家族的一名成員，它幫助架構(gòu)師和開發(fā)人員管理他們在軟件開發(fā)項目中不得不面對的形形色色的復(fù)雜性。與其他廣為人知的DDD模式相比，上下文圖可以應(yīng)用在任何軟件開發(fā)的場景中，在開發(fā)者進(jìn)行策略性決策時，為他們提供一個高層視圖，比如是采用全套的DDD實現(xiàn)，還是根據(jù)項目的特定條件進(jìn)行取舍等。

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

　　多個模型共存

　　領(lǐng)域驅(qū)動開發(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)境，鼓勵學(xué)習(xí)與探索。

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

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

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

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

　　了解“界限上下文”

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

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

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

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

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

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

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

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

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

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

　　繪制第一份上下文圖

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

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

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

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

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

　　圖4. 精簡版本的BankingAccount類

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

　　圖5. Payee類與BankingAccount類

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

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

　　圖6. BankingAccount和PayeeAccount類

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

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

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

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

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

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

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

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

　　管理多個上下文

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

　　有一件事情非常關(guān)鍵，即兩個上下文之間的聯(lián)系是有方向的。DDD用兩個專門的術(shù)語表述它們：“上游（upstream）”和“下游（downstream）”，一個上游上下文會影響到相應(yīng)的下游上下文，但是反過來就不一定了。這不僅體現(xiàn)在代碼上（一個庫依賴于另一個），還體現(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），它會在代碼層面上實現(xiàn)顯式的轉(zhuǎn)換，轉(zhuǎn)換可以在兩個上下文之間，或者在“銀行”上下文的外部邊界上完成。這不僅局限于技術(shù)上的轉(zhuǎn)換，比如Java轉(zhuǎn)化為XML，同時也是一個很合適的機(jī)會，能夠管理各個模型之間的所有微妙的不同。如下面的圖10所示，我們在上下文圖上添加了ACL。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　結(jié)論

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

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

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

　　關(guān)于作者

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

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

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

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