作者簡介：張剛，軟體工程博士，阿裡雲雲效資深技術專家，ALPD方法學核心成員。
讀者福利：前往：
https://developer.aliyun.com/topic/course/alpd 免費領取阿裡爆款架構師課程《DDD高手進階12講》（原價98元）。引言
領域模型是重要的概念。但是，真正了解并能熟練運用它的人并不多。這實在是殊為可惜的一件事情。
軟體開發中的許多問題，例如需求難于溝通，軟體難以演化，都和領域模型緊密相關。更關鍵的是，掌握這個概念并不難。通過練習，一個團隊隻需要一兩個小時，就可以習慣領域模型的模組化思路，并且開始從中受益。
那麼，什麼是領域模型？如何了解領域模型的本質？為什麼領域模型能給軟體開發帶來巨大幫助？如何表達它，如何應用它？本文将依次展開這些概念。
什麼是領域模型？
首先我們來看什麼是領域模型。
領域模型定義了領域内的關鍵的概念以及這些概念之間的關系。
為什麼要強調“領域内”？是因為模型（或者說概念）隻在它所處問題空間中才有意義。這分為兩種情況：
1）一個概念隻在某個特定領域有意義。例如，“應收賬款”，就隻是在财務領域，更嚴格的說是會計領域才有意義。
2）一個概念必須通過領域限定，才有具體的意義。例如，“軌道”這個概念，它可能是天文學領域的行星運動軌道，也可能是鐵路領域的火車軌道，必須得先限定領域，這個概念才有真正的價值。
關鍵資訊1：領域模型最重要的是概念，領域模型也被稱為概念模型。
雖然有人說“領域模型是領域内的概念的可視化表示”，但是， “可視化”并不本質，雖然它也重要。相比較而言，“概念”才是根本。
關鍵資訊2：“語言的邊界就是思想的邊界”—— 一個好的領域模型，必然承載了有用的知識。
對一個不熟悉特定領域的人來說，了解概念，往往是進入一個領域最快的方式。例如，小時候的兒歌：太陽大，地球小，地球繞着太陽跑。地球大，月亮小，月亮繞着地球跑。它就可以認為是一種概念模型的表達。在這個模型中，包括了3個概念實體：太陽，地球和月亮。而太陽和地球的關系是地球繞着太陽運動，地球和月亮的關系是月亮繞着地球運動。用一張圖畫下來就是：
這張圖其實是UML的對象圖，當然即使你不熟悉UML，就是作為線框圖，也能很容易了解。
同樣，在各種業務領域，都有自己的關鍵概念。這些概念的表達也不一定是圖。例如，剛才所講的會計領域，我們可以使用一張表來表達下列的幾個關鍵概念：
| 會計主體（本方）->對方 | |
| 應收賬款 | 貨物已經發給對方，但是尚未收到貨款 |
| 應付賬款 | 已經收到對方貨物，但是尚未支付貨款 |
| 預收賬款 | 已經收到對方貨款，但是尚未發貨 |
| 預付賬款 | 已經支付對方貨款，但是尚未收到貨物 |
通過這樣一張表格，相信即使對會計領域不甚了解對小夥伴，也能快速掌握相關的知識。如果我們更進一步，能夠了解到，應收和預付，本質上是本方的債權，而預收和應付，本質上是本方的債務。用一張圖表示就是：
在這裡我們使用了UML類圖來表示。對于不熟悉UML的小夥伴，可能需要解釋一下三角形箭頭的意思，它代表“是一種”，例如，應收賬款是一種債權。
更嚴格的，如果一筆應收賬款的帳期已經很長，例如5年，那麼這種賬款有很大機率已經收不回來了，是以需要計提壞賬。有一些通用的壞賬計提政策，例如：一年以内5%，一到二年20%，二到三年50%，三年以上100%等。是以，面向剛才的應收賬款，我們可以用下面的圖來表達這樣的概念：
圖是一種視圖，它不需要面面俱到。例如，本圖中，并沒有顯示一切和會計科目相關的資訊，而隻是集中于壞賬的計提。其中，我們在應付賬款和壞賬之間引入了一個新的符号，認識UML的小夥伴知道我們表達的是”應收賬款中包括壞賬“。圖中的帳期、金額等，我們成為“屬性”，用于詳細的說明應收賬款、壞賬這些概念還包括哪些内容。
由于領域模型本質上傳遞的是概念，是知識性的資訊，是以，對于軟體開發的場景來說，把這些知識顯式化，能快速對齊不同角色、不同參與方之間的概念，加速溝通，避免誤解。
領域模型是重要的業務資産
領域概念沉澱業務知識，而且非常穩定。
一家在某個領域深耕多年的企業，和一個新入行的企業，差别是什麼？差距可能是多方面的，但是最大的差距應該是“認知”。——是以我們常常會看到，新入行的企業追趕深耕多年的企業的辦法，常常是去成熟的的企業高薪“挖角”。按道理說，挖來的這些人既不能把原公司的客戶帶來，也不可能把原公司的系統帶來，那麼本質上他們給新企業帶來了什麼呢？他們對新公司最大的幫助，是對特定領域的認知。在業務領域，認知非常值錢，而且非常穩定。我們也會看到，一些在某個領域建立了優勢的企業，特别是咨詢類企業，單靠業務領域的咨詢，就能給企業帶來客觀的收入。如果有良好維護的領域模型，那麼領域模型就是這些認知沉澱的最佳位置所在。
更重要的是，盡管業務常新，但是領域模型卻相當穩定。我們以商品交易為例。我們知道買家、買家、商品、交易這些概念，都是商品交易領域的核心概念。這些概念并不會随着業務的演進發生劇烈的變化，無論是B2C業務，C2C業務，C2M業務，拼團業務還是秒殺業務。不同的業務，展現的隻是對這些業務概念的不同組織方式。當然，真正的領域模型要遠遠比上述概念複雜的多。我們這裡隻是舉一個簡單的例子，說明領域概念的穩定性。
領域模型的躍遷和生長
當然，我們說領域模型穩定，并不是說它一成不變。優秀的領域模型都一定會持續生長，甚至有時候會發生本質的躍遷。
一旦一個模型被推翻，我們會認為，我們對某個領域的認知，一定發生了非常本質的躍遷。例如，前述的兒歌“太陽大，地球小，地球繞着太陽跑。地球大，月亮小，月亮繞着地球跑。”并不是一開始就是這樣認知的。無論中外，在幾百年前，我們都曾經認為，地球是宇宙的中心，太陽、月亮都是繞着地球運作的。那麼，這個模型畫出來就是下面這個樣子：
地心說對象圖
地心說到日心說，是我們宇宙認知到巨大進步，以為日心說模型徹底否定了地心說模型。在軟體領域也是這樣。我曾經經曆過幾次領域模型躍遷的場景，每次都伴随這業務認知的巨大進步。
當然，在現實生活中，躍遷并不多見。更多的時候都是在原有的模型上穩定發展，逐漸增入各種新的概念和各種細節。模型的生長過程，本質上也是業務能力積累的過程。
穩定的領域模型帶來軟體的适應性
需求是不穩定性的，而領域模型是穩定的，這啟發我們，如果以領域模型為中心去構造軟體，那麼我們就會構造出很多穩定的積木塊。新的需求，就可能通過這些穩定的積木塊，通過不同的搭建方式，形成豐富多彩的應用。在這種情況下，我們的軟體對于變化的适應力最強，開發成本最低。
領域模型存在于哪裡
用類圖表示領域模型
UML類圖是表達領域模型的非常好的工具，雖然并不存在如何表達領域模型的标準。因為在UML中，“類”并不簡單是軟體設計中的“類”，它代表的其實是“概念”，是以，把類圖用在領域模型的表達上，是非常恰切的。而且，UML已經約定了概念和概念之間的關系，例如：類、屬性、關聯、關聯的多重性、泛化、聚合、組合、依賴等等。
對于不熟悉UML的人來說，使用UML也完全沒必要有什麼心理負擔。UML是一個高度靈活的結構，它具有漸近的能力。你沒有必要掌握所有複雜的概念才開始工作，根據我的經驗，隻要一開始能把類（代表概念）、類的屬性和它們的關系描述出來，最多再知道多重性怎麼表示，就足以應付大多數的場景。
有些小夥伴有面向對象的經驗，在這裡會糾結于要不要對“方法/操作”進行模組化。在“領域模型”是一種“業務概念”這個上下文中，方法是完全多餘的東西，暫時不需要在這個階段進行模組化。我認為在實作階段補足它們更合适。
在交流和文檔中使用領域模型
領域模型寫在紙上并不是最關鍵的。作為概念模型，它反映了這個領域的最重要的概念，也構成了表達業務概念的詞彙。是以：
最好的領域模型，應該時刻存在于團隊成員的心中，存在于日常的交流活動中。
為了做到這一點，我對自己的團隊和輔導過的團隊，都有一個要求，這個要求也被成為交流活動中的“統一語言”：
任何在需求描述中出現的概念，都必須出現在領域模型中。如果需求描述中存在概念之間的關系，領域模型中也必須有這個關系
這個要求看似簡單，實際做到會比較困難。特别在剛開始的時候，團隊成員可能并不适應這種做法，常常就忘記了這個準則，需要經常糾正。但是一旦習慣，大家會發現，在日常交流活動中，因為所有的概念都已經顯式化，誤解大大減少，共識更容易達成，導緻的後果就是最後團隊成員，都會非常自覺的維護“統一語言”的做法。
出于同樣的原因，編寫文檔時，使用領域模型作為統一語言也成了一個非常自然的結果。
在代碼中使用領域模型
由于領域模型已經被顯式化，是以如果能夠在代碼中使用領域模型，那麼代碼就會獲得更好的易讀性。由于領域模型和代碼對應的更加一緻，那麼在領域模型發生演進時，代碼就會變得更容易演進。在這方面，領域驅動設計給出了一組完備的模式，可以幫助架構師和開發人員自然地把領域模型轉化為代碼。本文中我們并不準備展開這些模式。在此，暫時先請讀者們記住下面的結論，後面會有更深入的讨論：
代碼和問題域之間的表示差距應該盡量縮小，領域模型是連接配接現實世界和數字世界的最佳橋梁。使用領域模型作為代碼中的業務概念的基本表達元素，可以大幅提升代碼的易讀性，也可以更好的支援業務的演進。
領域模型來自哪裡
領域模型反映了關鍵的業務認知，但是認知并不會憑空建立。能夠一上來就洞悉一切本質的，要麼是這個人是天才，要麼說明這個領域已經是一個非常成熟的領域，已經無需探索和發現。
大多數時候，認知都來自于業務場景的啟發。是以，領域模型建立的過程，往往是伴随着需求分析同步産生的。
我畫了下面這張圖，來說明領域模型和業務場景之間的關系：
也就是說，領域模型是在業務場景的激勵下逐漸完善的。而且，反過來因為對領域的認知更加深刻，領域模型還有助于新的業務場景的發現。
探索和發現最好不要一個人獨自進行。更多地時候，應該盡量進行集體模組化。集體模組化不僅僅利于探索和發現，而且它也有助于達成對于關鍵業務概念的共識。
集體模組化的最好工具并不是UML的電子化工具，使用白闆，在開放空間中的讨論，往往能夠收到最好的效果。
由于領域模型表達的是概念，是以對于概念及時地分解和抽象，是領域模組化的基本功。當然，現實中受過嚴格的分解和抽象訓練的人并不多，特别是很多業務人員往往都缺乏這方面的能力。我在實際工作中，觀察到具有面向對象經驗的開發人員，經過一定時間的練習，可以很快掌握這方面的技能。是以，如果有一些具有經驗的開發人員參與模組化，往往可以獲得品質更高的模型。
常見誤區
領域模型的概念産生于90年代的面向對象社群。在那個時候，業務變化還不像今天這樣頻繁，疊代的思想也還沒有完全成熟，業務人員和技術人員也沒有像今天這樣密集的交流，是以，無論是從參考書上，還是實踐上，領域模型的概念都難免留下早年做法的影響。其中，有若幹誤區，在實踐中是應該盡量避免的：
誤區1: 從開發視角進行領域模型的模組化
常常有技術人員問：“領域模型和ER圖有什麼關系？” 對這個問題最直接的回答就是：“沒有關系”。固然，我肯定知道在有了領域模型之後，設計ER圖會更簡單，或者對于一個還缺乏領域模型的遺留系統，研究資料庫結構可以帶來有效的輸入，但是它們的立足點是完全不一樣的。
領域模型一定要從業務視角去看，因為領域模型反映的是業務認知。一旦在領域模型中摻雜了技術的概念，不僅僅是因為它不夠純粹，更重要的是它已經堵死了從業務視角對領域模型進行演進和糾正的機會。因為沒有軟體背景的業務人員，是不可能去看一個充斥着技術概念的模型的。統一語言無法建立，領域模型帶來的價值就已經損失了一大部分。此外，從開發視角進行模組化，往往還會忽視業務人員的參與。而實踐一再表明，資深的業務人員在領域模組化時，往往能提出深入的洞察。是以，從開發視角對領域模型進行模組化絕對不可取。
誤區2: 建立龐大的領域模型
當我們說“領域”的時候，并沒有限定一個“領域”應該有多大。究竟是“航空”作為一個領域，還是“航空”中的“訂票”是一個領域？
當你考慮到“領域的核心是認知”，這個答案就變得非常清楚了。領域越大，越不利于建立認知和共識。我們應該這問題域，把大的領域劃分為小的領域，然後逐個建立這些小的領域的領域模型。那種整整一面牆的領域模型，往往都是不可取的。
誤區3: 重文檔，輕交流和共識
領域模型的核心在于建立共同的共識，是以，如果隻是把領域模型作為一種“制品”，作為某個階段的“輸出”，這是非常不合适的。領域模型需要作為交流工具。“統一語言”是避免該誤區的重要方法。
誤區4: 不把領域模型顯式化
很多人認為自己是有“認知”的，甚至是有“領域模型”的，但是，如果你問他們模型在哪裡，這些要麼就是在某個項目曾經有過一些讨論，但是現在已經不知所蹤，要麼就是雖然文檔還在，但是團隊的概念表達依舊混亂。沒有顯式化，沒有把領域模型寫下來，沒有形成團隊口口相傳的知識，那麼這種模型，并不真正存在。除了“統一語言”，我們還有一個非常簡便的檢驗方法，就是看這個團隊如何給新人介紹自己的系統。因為領域模型反映了基本的業務概念，是一個非常好的新人培養工具，但凡真正有“領域模型”的組織，是不可能不把領域模型拿出來做介紹的。
總結
本文我們主要介紹了領域模型的基本概念及重要度，領域模型對于“統一語言”的價值以及領域模型應用的常見誤區。
總結一下要點：
- 領域模型的本質是概念和認知，它定義了領域内的關鍵概念以及這些概念之間的關系
- 相對于業務的多變，領域模型相對穩定，優質的領域模型可以低成本的支援業務，領域模型也是統一語言的基礎，能有效提升溝通效率
- 領域模型來自于業務滋養，領域模型生長的過程，也是業務認知建立的過程，協作模組化是更有效的模組化方法
在你的團隊中，有顯式的領域模型和共同的業務認知嗎？它在指導日常的交流和開發工作嗎？如果還沒有，讓我們開始吧。
課程推薦：《DDD高手進階12講》
本文内容源自阿裡雲雲效推出的《ALPD雲架構師系列——DDD高手進階12講》。這是一門阿裡内部的爆款課程，獲得數千阿裡工程師口碑推薦，值得每位開發者反複學習。
或PC端前往如下連結擷取課程，免費領取阿裡爆款架構師課程《DDD高手進階12講》（原價98元）