經常聽到領導教誨，開發的同事應該要往前走一步，去做產品？去做售前？這也是一種方式，只不過是一大步。個人覺得，在邁出這一大步之前，需要先走出一小步：從寫好代碼到做好設計。
下圖是按照軟件工程的通用做法，梳理出的標準設計指南，已經非常清晰地定義了軟件設計的階段和活動，產物規約，文檔要求以及需要配合的培訓。比較適合於人朋規模大、產品化程度高、外包服務模式。按照這個標準的設計指南，把每一階段的事情做好，這是標準的開發方法論的實踐指導。
有人會說，現在是移動互聯網的時代，我們的產品開發要求短、頻、快地上線，這種標準的設計方法已經不適合了，我覺的不完全正確。我的做法是，根據產品的願景和市場情況，按照標準的設計指南做一些定製性的剪裁，哪怕文檔全部裁完了，腦子裏分析時仍然要按照這幾個階段開展對應的活動，因爲這不僅是指南，更是方法論，針對這個幾階段開展過的活動，下面就梳理下我的設計經驗。
首先是需求捕獲和分析階段，總是感覺需求在不斷地變化，老是怪市場和產品經理，其實很多情況是我們對需求的理解不到位。既有業務理解不準確，也有支撐方式不合理。還有一點就是將原型與需求沒有進行區分，原型不代表需求。將需求分析劃分爲業務需求與系統需求兩個階段，做好領域分析，才能根本性地適應需求的不斷地變化。
接下來談談如何做好系統分析，在這個階段一般又叫建領域模型，又叫概念模型，分析對象模型，它專注於分析問題領域本身，發掘重要的業務領域概念，並建立業務領域概念之間的關係。領域模型設計是需求分析的關鍵步驟。它幫助用戶及需求分析人員建立業務概念，確定用戶業務的問題域，系統涉及的業務範圍等等。
領域模型設計的一般步驟爲：
1、從業務描述中提取名詞
2、從提取出來的名詞中總結業務實體，區分名詞中的屬性、角色、實體、實例，形成問題域中操作實體的集合；
3、從業務實體集合中抽象業務模型，建立問題域的概念
4、用UML提供的方法和圖例進行領域模型設計、確定模型之間的關係。注：實體之間的關係，主要有泛化、依賴和關聯，關聯又分了一般關聯、聚合、組合等
簡言之，先分析出模型實體，然後找出模型實體之間的關係。
領域模型與實數據模型的關係：領域模型是與用戶溝通的一個重要工具，是需求分析人員與用戶共同理解的概念，是彼此之間交流的語言。它是一個分析模型，描述的是業務中涉及到的實體及其相互之間的關係，它是需求分析的產物，與問題域相關。同時給我們需求分析人員和系統功能提供了一定的擴展視野，看到將來需求的可能變化或可能存在的問題。而數據模型是系統設計、實現的一部分，描述的是對用戶需求在數據結構上的實現，當然數據模型中的概念模型設計與領域模型類似，缺乏的是實體之間更廣泛的關係描述。
這裏以開放平臺業務管理爲例，設計出的領域模型圖紙，歡迎大家拍磚。
