普通開發者在開發乙個專案時，可能考慮到的都是如何實現業務邏輯，同時提高程式效能，好一點的開發者會同時考慮到**的復用性和擴充套件性，沒錯，上面提到的幾點都是乙個優秀的技術開發需要必備的素質，但是如果想要真正的做出好的專案，是需要深入了解專案所屬領域的專業知識，從而設計出易於維護，能夠滿足組織後續需求，可以不斷演進的複雜軟體。
很多專案最主要的複雜性往往不在技術上，而是來自領域本身、使用者的活動或業務，當這種領域複雜性在設計中沒有充分考慮並得到解決時，基礎技術的構想再好也無濟於事。所以為了達到終極目標，往往需要在專案開發前進行充分的頭腦風暴和建模，通過領域模型，提公升開發人員與領域專家之間的溝通質量。概括起來就是基於模型的溝通。
軟體的核心是為使用者解決領域相關的問題的能力，所有其他特性，不管有多麼重要，都要服務於這個基本目的。
舉乙個很簡單的例子，假如我們有乙個需求，運營人員需要乙個後台去檢視和管理我們的資料，目的是為了通過資料了解使用者行為喜好，設計出更好的軟體系統。首先我們分析下專案的核心是什麼？檢視和管理資料，所以資料的直觀性和準確性才是軟體的核心，而ui的美與醜，並不是我們需要關注的核心問題，如果我們把精力放在介面的美化上，專案週期拖長，最終會影響運營人員的工作效率。
模型和實現的繫結：我們的**實現應該基於模型的設計，並且在後續的迭代中，需要持續維護模型。
建立一種基於模型的語言：俗話說，隔行如隔山，當我們新接觸乙個專案時，在第一次和產品經理溝通中，他們不得不向我們解釋最基本的概念和邏輯，而我們也必須向他們解釋我們實現上的大致思路，這都是有必要的，會推送最終專案的結果趨向完美。隨著專案的進展和迭代，雙方都能直接使用模型中的術語溝通，無需想辦法翻譯成對方能夠聽懂的話術。
提煉模型：在模型日趨完善的過程中，重要的概念不斷被新增到模型中，無意義的概念則從模型中被移除，隨著時間的推移，溝通會變得越來越高效。
頭腦風暴和實驗：語言、草圖、頭腦風暴，是高效溝通的三要素。
高效的領域建模人員是知識的消化者，他們在大量資訊中探尋游泳的部分，不斷嘗試各種資訊組織方式，努力尋找對大量資訊有意義的簡單檢視。知識消化並非一項孤立的活動，它一般是在開發人員的領導下，由開發人員與領域專家組成的團隊共同協作。他們共同收集資訊，並通過消化而將資訊組織為有用的形式。資訊來自領域專家頭腦中的知識、現有使用者、以及技術團隊在類似系統中積累的經驗。
在傳統的開發流程中，業務專家對問題進行討論，消化理解知識點，抽象成文件傳遞給程式設計師，再由程式設計師編寫軟體**。這種方式完全沒有反饋，因此結果很容易失敗。即便不會失敗，也會在開發的過程中反覆反饋問題，調整需求設計，不僅會影響開發人員的整體構思，同時會嚴重影響專案週期（這個問題在我所在團隊經常出現）。
乙個好的開發流程，應該是業務專家和研發人員頭腦風暴共同產出的，雖然這種形式 表面看似會浪費很多時間在開會溝通上，但往往在這個過程中會暴露出很多設計中的問題，同時可以過濾掉一部分非核心的問題，強化核心問題。
專案所在領域的知識往往分散在不同的文件中， 其中夾雜著一些無關的資訊，因此可能我們並不知道哪些是我們需要的知識。看似沒有什麼技術難度的領域很可能是一種錯覺，我們並沒有意識到自己不了解的東西究竟有多少，很可能錯過了關鍵核心。高效率的團隊要有意識地積累知識，並堅持對所在領域進行學習，對於開發人員既要完善技術知識，也要培養領域建模技巧。
if ($order->status == 4000)if ($orderisshow($order))
function isshow($order)
摘譯 面向領域建模
還是原來我在blog中提到過的，微軟的思路 dsl，包括現在說的dsm，其實都是或者說來自mda的思路。只不過是 1 不是用的uml的標準。2 現在通過領域限定來降低目前實現mda支援的難度。而且和微軟的大多數產品一樣，微軟做的東西易用性上會好一些，這一點足夠重要。dsm規避了mda發展中的難題，不...
鄧麗君的領域建模
建模競賽題第2賽季第22輪 請根據以下資訊畫出系統的分析類圖。6分 所有回答者都可以得分。總分數根據時間和答案質量綜合評定，回答時間靠後的分數打折扣，折扣係數0.05。舉例 第乙個答，答案質量得分4分，總分4分 第5個答，答案質量得分5分，總分5 1 5 1 0.05 4分。如果有人喜歡一首歌曲，他...
業務領域建模Domain Modeling
每個業務都有乙個對應的業務模型，這個業務模型設計的時候，完全不需要考慮任何軟體設計的思想，比如物件的抽象 繼承 儲存 效能，等。我們是從業務本身出發，分析業務邊界範圍內的各種業務概念，以及業務概念之間的關係，通常我們可以使用乙個業務模型的圖來表達這些業務概念以及業務概念之間的關係。那麼如何得到乙個業...