領域建模是對領域內的概念類或現實世界中物件的視覺化表示。又稱概念模型、領域物件模型、分析物件模型。它專注於分析問題領域本身，發掘重要的業務領域概念，並建立業務領域概念之間的關係。領域驅動設計分為兩個階段：
1. 以一種領域專家、設計人員、開發人員都能理解的「通用語言」作為相互交流的工具，在不斷交流的過程中不斷發現一些主要的領域概念，然後將這些概念設計成乙個領域模型；
2. 由領域模型驅動軟體設計，用**來表現該領域模型。
由此可見，領域驅動設計的核心是建立領域模型。領域模型在軟體架構中處於核心地位；軟體開發過程中，必須以建立領域模型為中心。
領域模型設計是需求分析的關鍵步驟。它幫助使用者及需求分析人員建立業務概念，確定使用者業務的問題域，系統涉及的業務範圍等等。
領域模型設計的步驟為：
1. 從業務描述中提取名詞；
2. 從提取出來的名詞中總結業務實體，區分名詞中的屬性、角色、實體、例項，形成問題域中操作實體的集合；
3. 從業務實體集合中抽象業務模型，建立問題域的概念；
4. 用uml提供的方法和圖例進行領域模型設計、確定模型之間的關係；
trufun已經開始針對各種不同領域的業務，建立領域模型庫，歡迎有需要的夥伴來電來信合作。
領域驅動設計告訴我們，在通過軟體實現乙個業務系統時，建立乙個領域模型是非常重要和必要的，因為領域模型具有以下特點：
1. 領域模型是對具有某個邊界的領域的乙個抽象，反映了領域內使用者業務需求的本質；領域模型是有邊界的，只反應了我們在領域內所關注的部分；
2. 領域模型只反映業務，和任何技術實現無關；領域模型不僅能反映領域中的一些實體概念，如貨物、書本、應聘記錄、位址等；還能反映領域中的一些過程概念，如資金轉賬，等；
3. 領域模型確保了我們的軟體的業務邏輯都在乙個模型中，都在乙個地方；這樣對提高軟體的可維護性，業務可理解性以及可重用性方面都有很好的幫助；
4. 領域模型能夠幫助開發人員相對平滑地將領域知識轉化為軟體構造；
5. 領域模型貫穿軟體分析、設計，以及開發的整個過程；領域專家、設計人員、開發人員通過領域模型進行交流，彼此共享知識與資訊；因為大家面向的都是同乙個模型，所以可以防止需求走樣，可以讓軟體設計開發人員做出來的軟體真正滿足需求；
6. 要建立正確的領域模型並不簡單，需要領域專家、設計、開發人員積極溝通共同努力，然後才能使大家對領域的認識不斷深入，從而不斷細化和完善領域模型；
7. 為了讓領域模型看的見，我們需要用一些方法來表示它；圖是表達領域模型最常用的方式，但不是唯一的表達方式，**或文字描述也能表達領域模型；
8. 領域模型是整個軟體的核心，是軟體中最有價值和最具競爭力的部分；設計足夠精良且符合業務需求的領域模型能夠更快速的響應需求變化。
我們認識到由軟體專家和領域專家通力合作開發出乙個領域的模型是絕對需要的，但是，那種方法通常會由於一些基礎交流的障礙而存在難點。開發人員滿腦子都是類、方法、演算法、模式、架構，等等，總是想將實際生活中的概念和程式工件進行對應。他們希望看到要建立哪些物件類，要如何對物件類之間的關係建模。他們會習慣按照封裝、繼承、多型等物件導向程式設計中的概念去思考，會隨時隨地這樣交談，這對他們來說這太正常不過了，開發人員就是開發人員。但是領域專家通常對這一無所知，他們對軟體類庫、框架、持久化甚至資料庫沒有什麼概念。他們只了解他們特有的領域專業技能。比如，在空中交通監控用例中，領域專家知道飛機、路線、海拔、經度、緯度，知道飛機偏離了正常路線，知道飛機的起飛。他們用他們自己的術語討論這些事情，有時這對於外行來說很難直接理解。如果乙個人說了什麼事情，其他的人不能理解，或者更糟的是錯誤理解成其他事情，又有什麼機會來保證專案成功呢？
在交流的過程中，需要做翻譯才能讓其他的人理解這些概念。開發人員可能會努力使用外行人的語言來解析一些設計模式，但這並非一定都能成功奏效。領域專家也可能會建立一種新的行話以努力表達他們的這些想法。在這個痛苦的交流過程中，這種型別的翻譯並不能對知識的構建過程產生幫助。
領域驅動設計的乙個核心的原則是使用一種基於模型的語言。因為模型是軟體滿足領域的共同點，它很適合作為這種通用語言的構造基礎。使用模型作為語言的核心骨架，要求團隊在進行所有的交流是都使用一致的語言，在**中也是這樣。在共享知識和推敲模型時，團隊會使用演講、文字和圖形。這就需要確保團隊使用的語言在所有的交流形式中看上去都是一致的，這種語言被稱為「通用語言（ubiquitous language）」。通用語言應該在建模過程中廣泛嘗試以推動軟體專家和領域專家之間的溝通，從而發現要在模型中使用的主要的領域概念。
擁有乙個看上去正確的模型不代表模型能被直接轉換成**，也或者它的實現可能會違背某些我們所不建議的軟體設計原則。我們該如何實現從模型到**的轉換，並讓**具有可擴充套件性、可維護性，高效能等指標呢？另外，如實反映領域的模型可能會導致物件持久化的一系列問題，或者導致不可接受的效能問題。那麼我們應該怎麼做呢？
我們應該緊密關聯領域建模和設計，緊密將領域模型和軟體編碼實現**在一起，模型在構建時就考慮到軟體和設計。開發人員會被加入到建模的過程中來。主要的想法是選擇乙個能夠恰當在軟體中表現的模型，這樣設計過程會很順暢並且基於模型。**和其下的模型緊密關聯會讓**更有意義並與模型更相關。有了開發人員的參與就會有反饋。它能保證模型被實現成軟體。如果其中某處有錯誤，會在早期就被標識出來，問題也會容易修正。寫**的人會很好地了解模型，會感覺自己有責任保持它的完整性。他們會意識到對**的乙個變更其實就隱含著對模型的變更，另外，如果**的**不能表現原始模型的話，他們會重構**。如果分析人員從實現過程中分離出去，他會不再關心開發過程中引入的侷限性。最終結果是模型不再實用。任何技術人員想對模型做出貢獻必須花費一些時間來接觸**，無論他在專案中擔負的是什麼主要角色。任何乙個負責修改**的人都必須學會用**表現模型。每位開發人員都必須參與到一定級別的領域討論中並和領域專家聯絡。
「使用者需求」不能等同於「使用者」，捕捉「使用者心中的模型」也不能等同於「以使用者為核心設計領域模型」。 《老子》書中有個觀點：有之以為利，無之以為用。在這裡，有之利，即建立領域模型；無之用，即包容使用者需求。舉些例子，乙個杯子要裝滿一杯水，我們在製作杯子時，製作的是空杯子，即要把水倒出來，之後才能裝下水；再比如，一座房子要住人，我們在建造房子時，建造的房子是空的，唯有空的才能容納人的居住。因此，建立領域模型時也要將使用者置於模型之外，這樣才能包容使用者的需求。
所以，我的理解是：
1. 我們設計領域模型時不能以使用者為中心作為出發點去思考問題，不能老是想著使用者會對系統做什麼；而應該從乙個客觀的角度，根據使用者需求挖掘出領域內的相關事物，思考這些事物的本質關聯及其變化規律作為出發點去思考問題。
2. 領域模型是排除了人之外的客觀世界模型，但是領域模型包含人所扮演的參與者角色，但是一般情況下不要讓參與者角色在領域模型中佔據主要位置，如果以人所扮演的參與者角色在領域模型中佔據主要位置，那麼各個系統的領域模型將變得沒有差別，因為軟體系統就是乙個人機互動的系統，都是以人為主的活動記錄或跟蹤；比如：論壇中如果以人為主導，那麼領域模型就是：人發帖，人回帖，人結貼，等等；ddd的例子中，如果是以人為中心的話，就變成了：託運人託運貨物，收貨人收貨物，付款人付款，等等；因此，當我們談及領域模型時，已經預設把人的因素排除開了，因為領域只有對人來說才有意義，人是在領域範圍之外的，如果人也劃入領域，領域模型將很難保持客觀性。領域模型是與誰用和怎樣用是無關的客觀模型。歸納起來說就是，領域建模是建立虛擬模型讓我們現實的人使用，而不是建立虛擬空間，去模仿現實。
以eric evans（ddd之父）在他的書中的乙個貨物運輸系統為例子簡單說明一下。
在經過一些使用者需求討論之後，在使用者需求相對明朗之後，eric這樣描述領域模型：
1. 乙個cargo（貨物）涉及多個customer（客戶，如託運人、收貨人、付款人），每個customer承擔不同的角色；
2. cargo的運送目標已指定，即cargo有乙個運送目標；
3. 由一系列滿足specification（規格）的carrier movement（運輸動作）來完成運輸目標。
從上面的描述我們可以看出，他完全沒有從使用者的角度去描述領域模型，而是以領域內的相關事物為出發點，考慮這些事物的本質關聯及其變化規律的。上述這段描述完全以貨物為中心，把客戶看成是貨物在某個場景中可能會涉及到的關聯角色，如貨物會涉及到託運人、收貨人、付款人；貨物有乙個確定的目標，貨物會經過一系列列的運輸動作到達目的地；其實，我覺得以使用者為中心來思考領域模型的思維只是停留在需求的表面，而沒有挖掘出真正的需求的本質；我們在做領域建模時需要努力挖掘使用者需求的本質，這樣才能真正實現使用者需求。
關於使用者、參與者這兩個概念的區分，可以看一下下面的例子：
試想兩個人共同玩足球遊戲，操作者（使用者）是驅動者，它驅使足球比賽領域中，各個「人」（參與者）的活動。這裡立下乙個假設，假設操作者a操作某一隊員a，而隊員a擁有著某人b的資訊，那麼有以下說法，a是b的映象，a是領域參與者，a是驅動者。
1. 使用者介面/展現層
負責向使用者展現資訊以及解釋使用者命令。更細的方面來講就是：
a) 請求應用層以獲取使用者所需要展現的資料；
b) 傳送命令給應用層要求其執行某個使用者命令。
2. 應用層
很薄的一層，定義軟體要完成的所有任務。對外為展現層提供各種應用功能（包括查詢或命令），對內呼叫領域層（領域物件或領域服務）完成各種業務邏輯，應用層不包含業務邏輯。
3. 領域層
負責表達業務概念，業務狀態資訊以及業務規則，領域模型處於這一層，是業務軟體的核心。
4. 基礎設施層
本層為其他層提供通用的技術能力；提供了層間的通訊；為領域層實現持久化機制；總之，基礎設施層可以通過架構和框架來支援其他層的技術需求。
鄧麗君的領域建模
建模競賽題第2賽季第22輪 請根據以下資訊畫出系統的分析類圖。6分 所有回答者都可以得分。總分數根據時間和答案質量綜合評定，回答時間靠後的分數打折扣，折扣係數0.05。舉例 第乙個答，答案質量得分4分，總分4分 第5個答，答案質量得分5分，總分5 1 5 1 0.05 4分。如果有人喜歡一首歌曲，他...
摘譯 面向領域建模
還是原來我在blog中提到過的，微軟的思路 dsl，包括現在說的dsm，其實都是或者說來自mda的思路。只不過是 1 不是用的uml的標準。2 現在通過領域限定來降低目前實現mda支援的難度。而且和微軟的大多數產品一樣，微軟做的東西易用性上會好一些，這一點足夠重要。dsm規避了mda發展中的難題，不...
業務領域建模Domain Modeling
每個業務都有乙個對應的業務模型，這個業務模型設計的時候，完全不需要考慮任何軟體設計的思想，比如物件的抽象 繼承 儲存 效能，等。我們是從業務本身出發，分析業務邊界範圍內的各種業務概念，以及業務概念之間的關係，通常我們可以使用乙個業務模型的圖來表達這些業務概念以及業務概念之間的關係。那麼如何得到乙個業...