基本概念
爲了創造一個好軟件，你必須知道這個軟件究竟是什麼。在你充分了解金融業務是什麼之前，你是做不出一個好的銀行業系統的，你必須理解銀行業的領域。讓軟件和領域和諧相處的最佳方式是讓軟件成爲領域的映射，軟件需要具現領域裏重要的核心概念和元素，並精確實現它們之間的關係。軟件需要對領域進行建模。一幅圖能夠描繪和傳達一個模型，同樣，經過精心編寫的代碼和一段英語句子都能達到這個目的。
模型是軟件設計中最基礎的部分。我們需要它，是因爲能夠用它來處理複雜問題。我們對領域的所有的思考過程被彙總到這個模型中。這樣甚好，但它必須要超越我們的頭腦，如果它止步不前，其實並不會有多大的作用，不是嗎？我們需要就這個模型跟領域專家進行交流，跟資深的設計人員進行交流，跟開發人員進行交流。模型是軟件的根本，但我們需要找到一些方法來表現它，讓它和其他事物交流。在這個過程中我們並不是孤立的，所以我們需要彼此共享知識和信息，而且我們需要把它做得更好、更精確、更完整，沒有二義性。要做到這點有多種方式。常見的一種方式是將模型圖形化：圖、用例、畫和圖片等。另一種方式是寫，我們會寫下我們對領域的願景。還有一種方式是使用語言，我們能夠也應該針對要交流的領域內的特定問題建立一種語言。在以後的章節中我們會詳細講解它們，但主要觀點是說，我們需要用模型來交流。
軟件設計類似於房子的架構和總圖相關，代碼設計更加細節，類似於在牆上定位一幅油畫。要想讓一幅油畫向左邊移動非常簡單，而想要拆除房子的一個邊卻是一個完全不同性質的事情。軟件設計方法：
- 瀑布設計方法：業務專家提出一堆需求同業務分析人員進行交流，分析人員基於那些需求來創建模型並作爲結果傳遞給開發人員，開發人員根據他們收到的內容開始編碼。在這個方法中，知識只有單一的流向。雖然這種方法作爲軟件設計的一個傳統方法，這麼多年來已經有了一定級別的成功應用，但它還是有它的缺點和侷限。主要問題是業務專家得不到分析人員的反饋信息，分析人員也得不到開發人員的反饋信息。
- 敏捷方法：在需求經常變化的情況下，要想預先創建一個覆蓋領域所有方面的完整模型確實很困難。需要做出很多的思考，而且開始時常不能看到涉及到的所有的問題，也不能預見設計中某些帶有負面影響或錯誤的部分。儘管敏捷方法的倡導者承認設計決定的重要性，但他們反對預先設計。相反，他們使用大量靈活的實現，通過由業務涉衆持續參與的迭代開發和許多重構，開發團隊更多地學習到了客戶的領域知識，從而能夠產出滿足客戶需要的軟件。
敏捷方法也存在自己的問題和侷限：他們提倡簡單，但每個人都對“簡單”的意義有着自己的觀點。同時，缺乏了真實可見的設計原則，由開發人員執行地持續重構會導致代碼更難理解或者更難改變。雖然瀑布方法可能會導致過度工程，但對過度工程的擔心可能會帶來另一種擔心：害怕做出深度、徹底的設計。
構建領域知識舉例
考慮一個飛機飛行控制系統項目的例子，看領域知識是如何被構建的，在一個給定的時刻，空中四處會有成千上萬的飛機。它們會朝着各自的目的地按照自己的路線飛行，很重要的事情是要確保它們不會在空中發生碰撞，爲了構建模型我們需要從與空中控制人員的討論中提取基礎知識並進行歸納。控制人員和你自己都認同每一個飛行器有一個起始機場和目的機
場。所以你找到了“飛行器”、“起始機場”和“目的機場”，見下圖。
那麼，飛機從某地起飛又在另一地降落。但空中發生了什麼？班機會按照什麼路線航行？事實上，我們更關心的是它在航行時所發生的事情。控制人員說會給每架飛機指派一個飛行計劃，飛行計劃會用來描述假定的整個空中旅行。當聽到“飛行計劃”時，你可能會在你腦海中想到這是一個飛機在空中必須遵守的路徑。在後邊的討論中，你會聽到一個有趣的詞：路線(route)。它能很快引起你的注意，這是個很好的理由。路線包含了飛機航行中的一個重要概念。那就是飛機在飛行時要做的事，它們必須遵照一條路線。很明顯飛機的出發點和目標點也就是路線的開始和結束點。所以，不同於將飛行器與出發點和目標點管理，看上去更自然的是將它與“路線”進行關聯，然後路線再與適當的出發點和目的地關聯。
跟控制人員交流飛行器需要遵照的路線時，你會發現路線由小的區間段組成，這些區間段按照一定的次序組織起來就會構成從出發點到目的地的一條曲線。這條線被假定穿過預定的方位點。所以，路線可以被考慮成一系列連續的方位點。從這個角度看，你不會再將出發點和目的地看作是路線的結束點，而只是將它們看作那些方位中的兩個點。這跟從控制人員的角度來看可能有很大的不同，但這是一個必要的抽象，對後續的工作會產生幫助。根據這些發現產生出來的變化結果如下：
這副圖顯示了另外一個元素，事實上路線中需要遵照的每個方位是一個在空間中的一個點，它表現爲一個 3 維的點。但當你跟控制人員交談時，你會發現他並不按這種方式思考。實際上，他將路線看作是飛機航班在地球上的映射。方位只是地球表面上的點，可以由經度和緯度來決定。所以正確的圖是：
實際上發生了什麼呢？你和領域專家在交談，你們在交換知識。你開始問問題，然後他們迴應。當他們這樣做時，他們從空中交通領域挖掘出基礎性的概念。那些概念可能看上去未經雕琢、沒有經過組織，但它們卻是理解領域的基礎。你需要儘可能多地從專家處學習領域知識。通過提出正確的問題，正確地處理得到的信息，你和專家會開始勾勒領域的骨架視圖，也就是領域模型。這種骨架視圖既不完整也不能保證是正確的，但它卻是你需要的開始點，可以盡力判斷出領域的基礎性概念。
通過與領域專家的交談，軟件設計人員的分析型思維會幫助他挖掘出一些領域中的關鍵概念，並且幫助構建出可用於將來討論用的結構，我們將在下一章中看到這種結構。作爲軟件方面的專家（軟件架構師和開發人員）和領域專家，我們會在一起創建領域的模型，這個模型會體現兩個專業領域的交匯。這看上去是個很消耗時間的過程，並且確實如此，但是它也應該被這樣做，因爲軟件的最終目的是去解決真實領域中的業務問題，所以它必須和領域完美結合。
通用語言
軟件專家和領域專家通力合作開發出一個領域的模型的過程中，溝通是非常重要的，由於軟件專家和領域專家都只瞭解他們特有的專業技能，爲克服這種交流方式的不同，在建立模型時，我們必須通過溝通來交換對模型和模型中涉及到的元素的想法，應該如何連接它們，哪些是有關的，哪些不是，軟件專家只有正確理解領域專家的思路，纔有機會獲得項目的成功。所以通用語言的重要性不言而喻，領域驅動設計的一個核心的原則是使用一種基於模型的語言。因爲模型是軟件滿足領域的共同點，它很適合作爲這種通用語言的構造基礎。
通用語言連接起設計中的所有的部分，建立了設計團隊良好工作的前提。可能會花費數週乃至數月的時間才能讓一個大規模項目的設計成型。團隊成員會發現一些初始的概念是不正確的或者不合適宜，或者發現一些需要考慮並放進總體設計中的新的設計元素。沒有了通用語言，所有的這一切都是不可能的。我們應該儘可能少地在需求溝通的場景中使用我們自己的行話，應該使用通用語言，因爲它能幫助我們更清晰更精確地交流。
我們可以使用文檔構建模型，一個明智的溝通模型的方式是創建一些小的圖，讓每副小圖包含模型的一個子集。這些圖會包含若干類以及它們之間的關係。這樣就很好地包括了所涉及到的概念中一部分。然後我們可以向圖中添加文本。文本將解釋圖所不能表現的行爲和約束。每個這樣的片斷都試圖解釋領域中的一個重要的方面，類似於一個聚光燈那樣只聚焦領域的一個部分。