一、項目的終極目標
普通開發者在開發一個項目時，可能考慮到的都是如何實現業務邏輯，同時提高程序性能，好一點的開發者會同時考慮到代碼的複用性和擴展性，沒錯，上面提到的幾點都是一個優秀的技術開發需要必備的素質，但是如果想要真正的做出好的項目，是需要深入瞭解項目所屬領域的專業知識，從而設計出易於維護，能夠滿足組織後續需求，可以不斷演進的複雜軟件。
二、如何實現終極目標
很多項目最主要的複雜性往往不在技術上，而是來自領域本身、用戶的活動或業務，當這種領域複雜性在設計中沒有充分考慮並得到解決時，基礎技術的構想再好也無濟於事。所以爲了達到終極目標，往往需要在項目開發前進行充分的頭腦風暴和建模，通過領域模型，提升開發人員與領域專家之間的溝通質量。概括起來就是基於模型的溝通。
三、軟件核心
軟件的核心是爲用戶解決領域相關的問題的能力，所有其他特性，不管有多麼重要，都要服務於這個基本目的。
舉一個很簡單的例子，假如我們有一個需求，運營人員需要一個後臺去查看和管理我們的數據，目的是爲了通過數據瞭解用戶行爲喜好，設計出更好的軟件系統。首先我們分析下項目的核心是什麼？查看和管理數據，所以數據的直觀性和準確性纔是軟件的核心，而UI的美與醜，並不是我們需要關注的核心問題，如果我們把精力放在界面的美化上，項目週期拖長，最終會影響運營人員的工作效率。
四、如何建模
4.1 有效建模的要素
- 模型和實現的綁定：我們的代碼實現應該基於模型的設計，並且在後續的迭代中，需要持續維護模型。
- 建立一種基於模型的語言：俗話說，隔行如隔山，當我們新接觸一個項目時，在第一次和產品經理溝通中，他們不得不向我們解釋最基本的概念和邏輯，而我們也必須向他們解釋我們實現上的大致思路，這都是有必要的，會推送最終項目的結果趨向完美。隨着項目的進展和迭代，雙方都能直接使用模型中的術語溝通，無需想辦法翻譯成對方能夠聽懂的話術。
- 提煉模型：在模型日趨完善的過程中，重要的概念不斷被添加到模型中，無意義的概念則從模型中被移除，隨着時間的推移，溝通會變得越來越高效。
- 頭腦風暴和實驗：語言、草圖、頭腦風暴，是高效溝通的三要素。
4.2 知識消化
高效的領域建模人員是知識的消化者，他們在大量信息中探尋游泳的部分，不斷嘗試各種信息組織方式，努力尋找對大量信息有意義的簡單視圖。知識消化並非一項孤立的活動，它一般是在開發人員的領導下，由開發人員與領域專家組成的團隊共同協作。他們共同收集信息，並通過消化而將信息組織爲有用的形式。信息來自領域專家頭腦中的知識、現有用戶、以及技術團隊在類似系統中積累的經驗。
在傳統的開發流程中，業務專家對問題進行討論，消化理解知識點，抽象成文檔傳遞給程序員，再由程序員編寫軟件代碼。這種方式完全沒有反饋，因此結果很容易失敗。即便不會失敗，也會在開發的過程中反覆反饋問題，調整需求設計，不僅會影響開發人員的整體構思，同時會嚴重影響項目週期（這個問題在我所在團隊經常出現）。
一個好的開發流程，應該是業務專家和研發人員頭腦風暴共同產出的，雖然這種形式 表面看似會浪費很多時間在開會溝通上，但往往在這個過程中會暴露出很多設計中的問題，同時可以過濾掉一部分非核心的問題，強化核心問題。
4.3 持續學習
項目所在領域的知識往往分散在不同的文檔中， 其中夾雜着一些無關的信息，因此可能我們並不知道哪些是我們需要的知識。看似沒有什麼技術難度的領域很可能是一種錯覺，我們並沒有意識到自己不瞭解的東西究竟有多少，很可能錯過了關鍵核心。高效率的團隊要有意識地積累知識，並堅持對所在領域進行學習，對於開發人員既要完善技術知識，也要培養領域建模技巧。
4.4 策略封裝
所謂策略封裝，是指的將一些單獨的邏輯封裝成函數塊，後續規則的更改無需影響核心流程代碼。比如我們的訂單評論系統，我們最初的策略是隻對結束的訂單展示評價（將來可能對訂單展示對規則進行調整），假如我們訂單結束的狀態是4000，一般開發寫的程序可能是下面這樣：
if ($order->status == 4000){
showComment();
}
好的代碼 往往如下：
if ($orderIsShow($order)){
showComment();
}
function isShow($order)
{
return $order->status == 4000;
}
五、總結
領域知識需要不斷學習和抽象，知識消化是一種探索，對領域模型的完善永無止境！