用領域驅動設計來評估商業現成的軟件
作者：Harald Wesenberg
Einar Landre
Harald Rønneberg
摘要：
購買一個商業現成的（Commercial-Off-The-Shelf，COTS）軟件包解決方案可能是一個複雜而且讓人畏縮的任務。選擇和評估正確的候選方案很困難，尤其解決方案瞄準公司業務的核心。必須保持公司的競爭優勢，同時確保實現預期的目標，比如，降低成本和更好的功能覆蓋。一個良好的企業架構應該是評估很多解決方案是否滿足公司需求的一個基本工具。
在本文中我們將列舉我們從評估三個COTS系統來替換一個遺產石油交易和運營系統中積累的經驗和教訓。基於我們企業架構中的弱點，我們採用戰略性領域驅動設計原則在評估過程中擴展我們的企業架構。我們發現這些技術使我們能夠和領域專家對我們的領域進行徹底的分析，並提供基於隱性領域知識的答案，而不是通過成本和進行大規模的架構分析工作。同時，隱性的領域知識更加顯式和共享，使得和利益相關者之間的交流更加愜意。
類別和主題描述：
D.2.11[軟件工程]：軟件架構
術語：
管理、理論、經驗
關鍵詞：
領域驅動設計、企業架構、上下文映射、職責層、信息架構
1．概述
Statoil正考慮用一個支持Wet Supply Chain（WSC）[5]的新系統替換一些遺留的軟件系
統。我們正考慮的選擇之一是通過購買一個商業現成的系統來滿足我們的部分需求。
需求信息（Request For Information, RFI）發佈出去之後，就收到許多提供商的迴應，而且其中的一些已經列入進一步評估和可行性需求提議（Request For Proposal, RFP）列表。我們計劃使用WSC的企業架構作爲其中的一個工具來評估每一個COTS候選方案對我們整個架構的滿足度。我們對幾個候選方案的以下幾個方面尤爲感興趣：
l 功能覆蓋面：這些候選方案如何滿足我們的功能需求；
l 信息模型：候選方案有沒有擁有必要的正確結構的信息來滿足我們的信息需求。
由於這個架構符合不同的候選方案，所以我們希望選擇其中的一個或多個進行RFP。
這個評估工作和我們採用領域驅動設計[3]和它的作用來擴展我們現有系統業務量[5]的企業架構相一致。當我們在採用企業架構中碰到困難的時候，我們決定嘗試使用領域驅動設計技術看看能不能讓評估工作繼續下去。
在我們繼續這份報告之前，有必要對企業架構和領域驅動設計做一個簡短的介紹。
1.1 企業架構（Enterprise Architecture, EA）
根據[1]，企業架構（EA）標識組織的主要組成成分，包括他的信息系統，各成分共同
完成某一預定目標的方法和信息系統支撐組織業務處理的方式。其中還包括職員、業務過程、技術、信息、財務和其他資源。
企業架構是基於整體論而不是特殊應用論。很多企業根據已有的框架，比如，TAFIM[6]，TOGAF[7]和Zachman[8]以及反映架構原則、標準和各個公司定義的應用模型，來開發自己的企業架構。這些框架提供了許多焦點來滿足不同能夠利益相關者的利益，比如，業務過程、信息、功能和技術基礎。
我們選擇企業架構作爲描述新的IT系統的基礎和現代化已有系統的策略。它必須爲開
發或購買一個新系統提供一個明確的途徑，並且應該是區分和優先考慮新項目的自然起點。爲了實現這一目標，它必須聯合業務和IT理念，標識業務需求和IT目標。
1.2 領域驅動設計
領域驅動設計是一種哲學，它的焦點是領域的錯綜複雜，它的目標是通過領域模型和
代碼實現使這些錯綜複雜的東西很明瞭。根據[3]領域設計的前提包括以下兩個方面：
l 對於很多軟件項目，關鍵的焦點應該是領域和領域邏輯；
l 複雜的領域設計應該基於一個模型來實施。
領域驅動設計不是一門技術也不是一種方法。領域驅動設計既是一種思考方式也是一系列要優先考慮的事情，其目的在於加速處理複雜領域的軟件項目。這些原則的主要來源是Eric Evans關於領域驅動設計的書[4]。
雖然領域驅動設計的首要目標是系統開發而不是COTS候選方案評估，但是源於領域驅動設計決策水平的上下文映射（context maps）和職責層（responsibility layers）對COTS的評估非常有用。
1.2.1 上下文映射
上下文映射是信息系統場景劃分到合適的通用功能組的映射。這樣每一個上下文都包含信息和上下文相關的功能。上下文的實例是物理原油交易（Physical Crude Oil Trading）（信息和功能關係到原油交易的過程）和原油供應運營（Crude Supply Operations）（信息和功能關係到把油從一個地方搬運另一個地方的操作）。上下文映射的另一個應用是映射出每一個信息系統與另一個信息系統之間的關係。[5]中的交易系統和供應運營系統就是這種上下文的實例。
一旦這些上下文得到確認，就可以調查分析每一個上下文之間的關係。基於關係、潛在的挑戰和交互問題，可能會標識和描述不同的上下文。最普通的關係主要有：
l 客戶/供應商：對於其它來說，一個上下文是供應商，當得到客戶上下文的請求時它提供信息和功能。上下文之間通過談判達成協議。
l 遵守常規：遵守常規的上下文的信息模型、功能和架構必須遵從資源上下文，永遠都不影響上下文的開發。
l 共享內核：兩個上下文共享一些通用的信息和功能，一個上下文的更新同時也更新另一個上下文。
早期我們在系統現有業務量上進行了各種各樣的上下文映射分析，發現這是我們
領域的固有屬性通信中非常有價值的工具。
1.2.2 職責層
在領域探索中，產生的領域模型一般呈現層狀，其中相似的對象歸爲一個組。比如我們找到的這種分層有：
l 能力：信息、功能與檢測、保持跟蹤在給定的上下文中可能因素有關。在現實世界，這就應該是股票水平、投遞義務、管道線基礎、容器的類型等。
l 操作：信息與功能和操作性任務的執行有關。在現實世界，這些任務主要有交易活動、供應操作等。通常，操作性任務依賴於能力層的信息。
l 決策支持：信息與功能和用戶的決策制定有關。在現實世界裏，這就是市場曝光監督、風險控制、供應計劃等。決策支持層一般依賴於操作層的信息，並且這個層的結果通常作爲將要執行的指令反饋給操作層。
雖然這是一個領域中職責層的三個實例，其他的領域將有不同的分層。關鍵在於這種分分層方法的識別，產生的領域知識是模糊的，但是現在已經很明確了。
2．利用企業架構
使用來自Scandinavian consultancy（斯堪的納維亞顧問工作）的方法，我們預先爲WSC開發了一個企業架構。通過業務、信息和功能組件來初始化這個架構，使用矩陣把不同組件的元素映射到一起將其擴展。這個信息架構大概定義了150個核心信息概念，分成20個信息組，把主要的領域概念作爲每一個組的組名。功能架構大概定義了120個業務功能，分成28個功能域。基於此，我們用一個20x28的矩陣來描述不同功能域中高層信息的用法。同樣的，我們映射了信息組和業務過程，功能域和業務過程。圖1是這種矩陣的一個摘錄。
圖1 企業架構摘錄
（矩陣被用來映射信息組和功能域，並且表示哪一個功能域創建/更新（●）或讀（○）哪一個信息組）
2.1 粒度問題
在COTS候選方案的評估中，我們試圖用我們的企業架構作爲一個工具來估計它們支持WSC的能力，但是很快就發現信息和解決方案組件的初始化粒度太粗了。
此類的一個實例是信息架構中沒有Deal這樣一個信息概念。當我們評估不同的方案時，不同產品對Deal的概念處理竟是千差萬別。然而，我們僅僅只用一個Deal概念，在企業架構中沒有明顯的不同。所以我們把初始的Deal分成多個不同的信息概念。Physical Deal和Derivative Deal.(派生的Deal)。通過這兩個新概念，每一個候選方案之間區別就明顯了。相似的我們不得不分解其他的概念（例如, Cargo, Voyage, Deliery）來說明不同方案之間的不同。當粒度變得更精細的時候，矩陣和評估就不可管理和不可通信了，只有項目的核心團隊能夠定位和理解評估中包含的關鍵信息。
另一個同類的實例是業務功能架構。和信息架構相似，初始化的架構有一個物理交易的功能域。當使用這個架構評估COTS候選方案時，我們發現他們的區別很大程度體現在功能域的覆蓋面。然而，我們不能使用信息架構或業務和信息架構的映射來舉例說明這一點。
2.2 缺乏固定的系統邊界
在評估中我們碰到的另一個問題便是缺乏固定的系統邊界。自從考慮了整體系統的業務量之後我們就把提議應用的功能挪到裏面去了，所以針對每一個COTS候選方案，我們不得不在應用中挪動功能，並且根據特定的COTS候選方案的覆蓋面把功能域細分爲不同的新組。企業架構在評價我們的工作結果或決定一個組是否優越於另一個組中沒有給予我們任何幫助。
2.3 隱式 vs 顯式知識
基於WSC架構團隊獲取的知識，我們感覺我們的企業架構包含許多不明確的信息。這些隱式信息能夠使我們決定如何給不同的COTS候選方案分配功能，但是我們不能共享這些隱式知識，以此來調整我們做出的決定。我們擁有使用戰略領域驅動設計技術的經驗，並且想看看它能否讓信息和知識更加明晰。
3．使用戰略性領域驅動設計
確認了我們企業架構的弱點之後，我們覺得必須擴展它，並且在COTS評估中使用它。這就需要相當的時間和在項目的這個階段我們沒有的工作。早期我們已經使用戰略性領域驅動設計技術來分析我們已有系統的業務量[5]，基於這些經驗我們設想在評估中採用相同的方法。
3.1 探索領域
我們從畫一個如圖2所示的簡單的上下文映射開始。這個映射把現有應用的不同功能域
歸到功能相關的上下文。由於在這個項目中基於SAP的功能沒有評估，所以我們把SAP系統的業務量所包含的所有應用域都包括在SAP上下文中。這樣就降低了圖的複雜性。這五個上下文構成了我們所有分析的基礎，隨着領域探索和COTS候選方案的評估進度的進展，我們經常把這五個上下文作爲起點來分析這個領域。
圖2 基於已有解決方案的應用域的簡單上下文映射
被SAP包含的所有應用域都包括在SAP R/3財務和會計上下文中。
我們的第一個任務是獲取整個領域的更加詳細的知識。在這個領域中，我們有很多領域專家專注於不同的上下文，但是幾乎沒有要求跨越很多領域的廣泛知識。這樣，我們啓動了幾個工作組配合這些專家來共同探索這個領域，每次至少數個小時。
3.2 使用職責層
基於工作組，我們很快就看到這個解決方案的很多功能域擁有共同的特點，基於這些特點我們馬上把這些域組織到職責層中。職責層是一個源於戰略性領域驅動設計的概念。作爲工具它們對管理領域的大部分非常有用。圖3所示的此類運用中，我們從解決方案到三個職責層重新分配了一些功能域。
圖3 從企業架構中選出來的功能域的職責層
在圖2中曾經用它來探索不同山下文之間的邊界（分析控制和派生交易上下文vs物理交易和供應操作上下文）。
職責層在功能域之間的依賴和決定系統邊界時那些層需要一起考慮等方面給了我們一個清晰的認識。我們認爲應該分爲能力、操作和決策支持三個層（和概述中的三個層一樣）：
l 能力層： 基本能力花費的層。圖3中Lifting Program是從域操作人員那兒接受所有可能的石油貨物的功能域。所有的可用石油貨物是交易和供應操作的基礎。在終止操作上下文（Terminal Operation context）之間有一個很複雜的邊界，但是這個圖中沒有表現出來。
l 操作：每日操作工作發生的地方。交易、供應操作和供應計劃是這類功能域的很好的實例。
l 決策支持：系統幫助用戶進行決策制定的地方。分析控制就是一個實例，各式各樣的市場風險就在這兒進行評估，而且最後的決策是基於這些評估而制定的。決策作爲派生交易指令反饋給操作層。
當畫完我們的職責層之後，我們增加了圖2中的邊界。我們發現兩個上下文之間的接口
是一個簡單的單向關係，結果是一個只有單向信息流而且不共享功能的不復雜的接口。同時我們發現這將是客戶/供應商關係（認同以上的C（Coustomer）和S（Supplier）），這樣風險控制所需的物理交易供應風險控制信息滿足了目標。
我們多次重複了這一過程，直到應用域映射出來，並搞定上下文關係的定義。在這
個案例中這些應用域在不同的職責層中，不過因情況而異。
4．評估COTS候選方案
經過一段時間的領域探索之後，我們已經對各種領域束手的方面有了一個很好的認識，
並認爲該是評估COTS候選方案的時候了。對於每一個候選的方案我們都是從粗略評估上下文覆蓋面開始，候選1的評估結果如圖4所示。從中我們不難發現這個候選方案有明顯的一些上下文覆蓋在方框之外，一些可能的擴展和一些沒有必要進行多大的修改就可以囊括到COTS中。
圖4 COTS候選方案1的上下文覆蓋分析。
顯示了哪些可以進行擴展，哪些如果不進行大幅度的修改或擴展不能包含
基於前期和領域專家們的討論，物理交易和供應操作上下文（關係到從挪威大陸架來的原油貨物的管理）的元素被標識爲一個核心領域。一個核心領域就是支持組織核心業務，對保持競爭優勢非常重要，它得到過程和應用有效的支持。我們最迫切希望知道COTS候選方案在這個上下文中的影響。
在分析過程中，我們發現前面使用的分析上下文已經不再正確了，因爲每一個COTS候選方案和其他的系統的功能覆蓋都不一樣。因此，我們放棄了我們原先使用的分析上下文，重新繪製新的，基於每一個COTS的特殊性的假定上下文。對於候選方案1，我們標識了幾個新的上下文並將其中的應用域分離。新的上下文如圖5所示。基於我們對COTS候選方案的認識，我們發現我們對原油供應計劃的需求幾乎沒有得到滿足，原油供應只被當作新的上文介紹。同樣的，我們發現也沒有包含一些我們更高一級的分析管理需求，並將高級分析管理作爲一個新的上下文來介紹。
圖5 從COTS候選方案1的分析中得出的新的推理上下文
對於我們來說COTS候選方案和原油供應之間的上下文邊界顯得很笨拙，因爲我們知道COTS候選方案所需的很多信息和功能也是原油供應上下文所需要的。我們決定通過使用職責層進一步調查這個邊界，同時隨着對領域的探索，我們發現這兩個推理上下文共享了一個如圖6所示的內核。
圖6 簡要的UML圖展示了三個領域對象在供應計劃上下文和COTS候選方案1之間存在一個共享內核。風險控制功能域作爲一個包顯示，從而不會因爲細節過多而造成混亂。
一個共享內核就是兩個上下文之間共享的一個信息和功能的集合。在這種情況下，一個共享內核包括了兩個上下文都需要的多個領域對象。在我們當前的系統中，這些領域對象在同一個系統中，並沒有構成一個上下文邊界。假如在這個共享內核上擁有系統邊界則說明：
l 應該在原油供應上下文中開發業務邏輯來複制COTS候選方案的功能；
l 原油供應領域模型必須接受COTS候選方案的命令；
l 偏離模型的代價就是構架一個“反腐壞”層的成本和複雜任務；
l 整合兩個上下文將非常昂貴而且困難；
l 共享內核不是在一個上下文內部提供的服務，因爲外圍不同的上下文都需要雙方的功能和信息。
原油供應上下文和COTS候選方案之間的共享內核的確認得以使項目組把注意力集中
到分析工作上，進一步調查功能覆蓋和信息需求。從分析的結果來看，我們可以明確這個方案不適合我們。
對於其他的COTS候選方案，我們生成了如圖4所示的基於相同上下文覆蓋評估圖。基於這些圖，我們在假定的實現上下文上儘自己的最大努力探索了這個領域。這強化了我們評估每一個候選方案對我們整個企業架構的滿足度。
經過對每一個候選方案，採用上下文映射，進行了一段時間的評估之後，項目組一致認爲沒有一個提議的COTS方案滿足我們的企業架構。因此項目組建議指導組，WSC的新方案需要基於客戶開發。指導組接受了這個建議，而且客戶開發在2006年秋季啓動。
5．結束語
我們啓動這個項目之前，利益相關者有一個明確的期望，在對COTS候選方案評估的
過程中企業架構一定會有幫助。但是，當我們嘗試使用企業架構時，我們發現這個架構不夠詳細，而且更加細節的擴展將導致無法使用我們的配置工具進行管理。相關的成本也將非常可怕，然而本文概述的方法使得我們在幾個工作組的努力基礎上達到一個良好而準確的結果。
這個項目中我們的經驗表明，通過戰略性領域驅動設計的技術來擴展我們的企業架構對以下幾個方面很有幫助：
l 通過通用語言促進領域探索。戰略性領域驅動設計給了我們一種通用語言，通過它我們可以討論這個領域。清晰定義的詞語和概念的應用使得不同的項目參與者可以理解，並致力於領域探索。
l 關注領域的核心方面。傳統的企業架構一致強調領域的所有方面。採用領域驅動設計技術，我們可以關注於對當前任務至關重要的領域方面，而不強調無關的方面。
l 讓隱式知識明確。通過採用職責層和上下文映射，我們可以標記我們領域內部的關係和依賴，因此從每一個項目組成員那兒獲取隱式知識，將其明確並和大家共享。
l 調查系統邊界。通過基於每一個COTS候選方案的推理上下文映射，我們可以更好的調查系統邊界並且確定整合不同的COTS方案是否昂貴和充滿挑戰。
在一個傳統的企業架構裏，這當然是可行的。這個結果本該在時間和金錢上耗費更多的
工作，而且更依賴於架構師的個人技能。
致謝
我們感謝Eric Evans對本文中個別內容，提供頗有幫助的討論以及他的監護能力。同時，我們感謝Olaf Zimmerman和ACM的敘述工作人員對本文準備過程中提供的幫助。
參考文獻
[1] Armour, Kaisler, Y. Liu, A big picture look at Enterprise Architecture, IEEE IT Pro January/February 1999.
[2] Armour, Kaisler, Valivullah, Enterprise Architecting: Critical Problems, IEEE Proceedings of the 38 HawaiiInternational Conference on Systems Sciences – 2005.
[3] Domain-Driven Design, http://domaindrivendesign.org/.
[4] Evans, E., Domain-Driven Design, Tackling Complexity in the Heart of Software, 2003, Addison-Wesley, ISBN 0-321-12521-5.
[5] Landre E., Wesenberg H., Rønneberg H., Architectural improvement through use of strategic level Domain-Driven Design, OOPSLA 2006 practitioner report.
[6] TAFIM, http://www.sei.cmu.edu/str/descriptions/tafim.html/.
[7] TOGAF, http://www.opengroup.org/architecture/togaf/.
[8] John Zachman http://www.zifa.com/.