領域模型可以成爲軟件項目通用語言的核心。該模型是一組來自於人員頭腦中的概念，一級反應了領域深層次
含義的術語和關係。
這種基於模型的交流並不侷限與UML(統一建模語言)圖，爲了最有效的使用模型，需要充分利用各種交流手段，
基於模型的交流提高了書面文檔的的效用。
一、通用語言
有經驗的軟件開發人員都會經歷這樣的事情，兩個人在爭論，但彼此說的確不是一件事，由於計算機是西方文明的產物，引入國內產生了很多翻譯，加上每個人的理解不同導致溝通不暢，純技術層的討論如果有第三人在場或許可以很快結束這種溝通。但如果是新組建的團隊去實現一個複雜的陌生業務，這種情況會變得更加頻繁，低效率的溝通是所有人工作的敵人。
領域專家有自己的術語（業務人員），產品有自己的語言，開發有自己的理解。
這時候需要一個人牽頭對開發過程中的業務術語進行統一管理
舉一個反例：
大規模分佈式系統中會有獨立的用戶中心，用戶中心提供了用戶註冊、認證、鑑權等服務，業務系統會對的接統一的用戶中心，對於用戶中心的開發來說，商城的業務線負責電商業務，金融的業務線負責消費貸業務，當兩個業務線協作完成消費貸流程時，三方的溝通就需要統一的語言，當電商的開發說：“用戶沒有留下地址”，金融的開發說：“用戶在申請借款的時候已經填了地址”。
雙發的溝通就會起波折。
UBIQUITOUS LANGUAGE的詞彙包括類和主要的操作名稱。語言使用的越普遍，理解進行的越順暢。
通用語言在實現領域驅動中往往會被忽略，筆者經歷的幾個使用了領域驅動設計的項目，沒有專門設置通用語言的環節，誠然當時的團隊彼此熟悉，業務熟練，大家溝通起來仍會發生彼此認知不一致的情況。
對於新的團隊，可以視情況，如果成員之間彼此磨合快，可以不必專門花費時間定義專業術語。
對於制定通用語言的劃分，個人認爲屬於產品團隊，從產品的需求提出便定義出通用的定義。
但遺憾的是，大部分產品經理沒有意識這個問題，甚至很大一部分軟件開發工作還是停留在口頭需求，邊做邊改的狀態，極大的影響團隊的效率
二、 一個團隊，一個語言
技術人員通產任務業務專家最好不要接觸領域模型，
他們認爲：
“領域模型對他們太抽象了”
“他們不理解對象”
“這樣我們就不得不用他們的術語收集需求”
在國外，開發工程師可以很大程度決定產品的設計，實現。
這種極客精神值得我們學習，國內軟件開發人員往往需要對產品提出的邏輯進行評審，和諧的團隊大家會商量一個實現，不和諧的團隊往往出現 產品和開發互相懟的情況。
對於團隊的溝通，考慮到國內情況，最好由項目經理完成，項目經理把控整個項目的排期，上線，瞭解業務，熟悉計算機專業知識，可以充分考慮到各方的情況。
有些計算機專業出身的產品經理，也可以勝任整個角色。
術語的交集產生 ubiquitous language
《領域驅動設計》page 34
三、文檔和圖
軟件設計文檔是一部分軟件工程師的額痛點，一般的大公司都有自己的文檔模板，文檔最全的公司應該是專業的外包公司，由於需要交付，文檔成了交付必備的內容。
對於互聯網行業，文檔往往不被重視，大多時候業務的壓力使得開發沒有時間擬寫文檔，甚至於產品的需求文檔都沒辦法給出。
3.1流程圖
無論你使用什麼模型來開發你的系統，流程圖都是必須的
對於團隊成員來說，流程圖都是通俗易懂的
流程圖偏向業務的理解。
注意團隊成員流程圖需要統一畫圖工具，流程圖可以存檔編輯。
3.2 交互圖
交互圖往往是泳道圖的形式，涉及到多個模塊的業務交互。
3.3 UML 模型圖
UML建模是領域驅動的基礎技能，對於大部分計算機專業也是必修內容。