2007年，世界級的軟件分析大師Eric Evans發表了他的經典著作《領域驅動設計》，進而形成了一套獨特的軟件分析與設計方法，簡稱為DDD（Domain-Driven Design）。在領域驅動設計思想中，有許多是涉及到需求分析領域的先進方法，我把它歸納為有效建模、統一語言和持續學習。

有人說：大師所站的高度實在太高了，是生活在太空里的，所以我們要追隨大師就只有因為缺氧而死掉。我認為這句話說得非常生動，學習大師真的不是一件容易的事，把大師的思想落實到我們的工作中更難，常常還伴隨著一些不小的風險，學習伊大師也是一樣的。

伊大師一上來就提出了要有效建模的思想，我當時立馬就暈菜了。按照這個思想，我們應當在業務研討會上，與客戶討論業務需求的時候就開始現場建模了。這！怎么可能呢？客戶看得懂那些專業的、抽象的模型嗎？我們能拿著模型與客戶交流嗎？這是不是在浪費時間？

的確，伊大師提出了有效建模思想，與其它很多諸如在會后分析整理時進行的原文分析方法大相徑庭。同時，這個思想認為，我們應當與客戶代表形成一種統一的語言，一種混合語言。這種語言，既有軟件技術中的元素，又有業務領域中的術語，同時，它又是技術人員與業務人員都能理解的語言。使用這個語言，技術人員與業務人員就是在用同一語言在溝通與討論問題，這種溝通的障礙就得以消除。

道理簡單實踐難，什么是有效的建模，什么是統一的語言呢？經過無數的實踐與嘗試，我逐漸開始明白了。首先，什么是有效的建模呢？當我們作為非專業人員去看一個建筑設計師繪制的圖紙時，我們一看就明白這是一棟樓房，那是一座橋梁，為什么？因為圖紙形象生動，沒有那么多專業術語，我們一看就明白了。軟件中的設計圖也是一樣的道理。

當我們站在技術人員的視角去繪制設計圖時，客戶必然看不懂，因為圖中使用的都是專業的術語、專業的符號，表達的都是專業的設計思想。反過來，如果我們站在業務人員的視角去繪制設計圖時，情況就不一樣了。如果一個用例圖，圖中的功能都是客戶日常經常做的業務操作，并且命名都是業務人員能夠理解的業務術語，試問客戶會不理解嗎？同樣，在領域模型中，我們按照客戶的思路，運用客戶的術語，去繪制一個一個的對象，按照他們的思路去描繪對象間的關系，描繪對象間的操作，他們真的就會看不明白嗎？這說得似乎有一些抽象，我們舉一個實際的例子吧。

有一次，我與客戶在討論一個考核系統，首先客戶描述著他們的需求：
客戶：我們這個考核系統是由許多個考核指標組成的，每個考核指標就標志著我們的某項工作的完成情況。每個考核指標中有一個分母數，標志某段時間所有應當完成的工作數量，有一個分子數，標志這段時間正確完成的工作數量，最后還有一個過錯數，標志那些錯誤的，或者沒有按時完成的工作數量。
需求人員：為什么是分子分母？
客戶：因為最后要計算正確率，用正確率來考核一個單位完成工作的情況。
這樣，我們在紙上繪制出一個考核指標，在屬性中寫下分母數、分子數、過錯數、正確率。

需求人員：那么每個考核指標都有一個過錯判斷標準了？
客戶：當然啦，每個考核指標都有它的過錯判斷標準。一個考核指標可能會有多個過錯行為，每一個過錯行為都有各自的過錯判斷標準，任何一個過錯了，這個執法行為就算過錯啦。
需求人員：先等等，你剛才提到執法行為了。執法行為和考核指標是什么關系？
客戶：哦，執法行為嘛，就是執法人員對某個用戶執行的一次業務操作。考核指標中的分母數就是所有執法行為的個數；分子數就是正確的執法個數；過錯數就是錯誤的執法個數。
這樣，我們就繪制出這樣一個草圖：



客戶看了這個草圖有些不同明白：過錯類型是什么東西？
需求人員：過錯類型就是某種類型的過錯行為呀，它定義了某種過錯行為，有它的過錯判斷標準。下面這個過錯行為就是那些具體的過錯，比如張三今天犯了什么錯，李四明天犯了什么錯。
客戶：哦，明白。這兩個箭頭怎么跟其它箭頭不一樣，后面還跟了個菱形框？
需求人員：哦，這代表的是包含關系，表示一個考核指標包含了多個類型的過錯行為呀。

經過一番交流，我們已經明白客戶的意思了，客戶也明白我們畫的圖了。大家對彼此的交流都比較滿意。

所有的愛情都是以浪漫開始的，需求分析也不如此。隨著需求分析的不斷深入，我們發現問題了。在這張圖中，我們把執法行為與過錯行為僅僅描述為一對多的包含關系，似乎沒有什么特別的。但對大量考核指標具體需求的分析，我們才發現其實不是這樣簡單。當考核指標只有一種過錯行為的時候，那非常簡單，這個過錯行為對就是對，錯就是錯。但當考核指標存在多種過錯行為的時候，情況就復雜了，必須分成三種情況：

1. 一個執法行為同時包含多種過錯行為，每個過錯行為就是一個考核點，任意一個考核點錯了整個就判錯，只有所有考核點都正確才判正確。這種情況就像填一個表單，所有數據項都填對了才算對，任意一個錯了就算錯，然后畫出這樣一個對象圖：



2. 雖然一個考核指標定義了多個過錯行為，但它把所有執法行為分為多個類型，每個類型的執法行為只對應一個過錯行為，這個過錯行為對就是對，錯就是錯：



3. 最后一種就是那些限期完成的考核指標，正確的行為只有一個：按時完成的行為，過錯行為卻有兩個：逾期完成與逾期未完成。



雖然圖形有些復雜，但這正是代表了現實世界業務的復雜性。我們拿著這些圖與客戶進行了簡單的描述，由于圖中的所有元素都是用客戶熟悉的術語描述的，因此他們很快就能夠理解。同時，開發人員拿到這樣一個圖，很快就制訂了四套不同的方案，來分別解決四種不同的情況。

隨后，在對這四種情況更加深入的分析時，我們發現第一種情況在計算過錯數時似乎有一些問題。在第一種情況中，一個執法行為包含了多個過錯行為，如果出現了過錯，過錯數算幾？假如一個執法行為包含三個過錯行為，如果都做對了，分子數算1；但假如有2個過錯行為錯了，過錯數算2？還有那一個正確的行為呢？這似乎有些矛盾！當我們向業務人員提出這個問題時，他也有些懵了，這樣的結果似乎是我們雙方都沒有預料到的。經過反復的思考與討論，最后我們做出這樣的決定：將原有的過錯數拆分成過錯戶與過錯數。在以上情況中，如果一個執法行為有2個過錯行為錯了，過錯戶為1，過錯數為2。試想，如果不對需求進行如此深入分析與理解，能發現這樣的問題嗎？如果不及早發現這樣的問題，是否會給項目后期帶來巨大的風險？

應該說，從最初的粗淺認識，深入到后來對四種情況的認識，正是體現了DDD的另一個思想：持續學習。需求人員在開始一個新的管理系統的分析工作時，都有可能面臨著一個全新的業務領域。在這個領域中，他們不可能一夜成為專家，也不必要成為專家。他們需要時間去學習領域知識，但這并不意味著學習所有的領域知識，而是與軟件相關的領域知識。做財務軟件，你不必考財務師，但你必須要學會與財務軟件相關的財務知識。你對領域模型的認識被延伸到了整個軟件生命周期中，包括之后一次一次的升級完善。你每認識深入一點兒，就可能會體現到你的分析設計中，并最終體現在開發的軟件中。你對領域知識認識再深入一點兒，軟件就再完善一分。

我們應當怎樣做需求分析
我們應當怎樣做需求調研：初識
我們應當怎樣做需求調研：拜訪
我們應當怎樣做需求調研：研討會
我們應當怎樣做需求調研：需求研討
我們應當怎樣做需求調研：迭代
我們應當怎樣做需求調研：需求捕獲（上）
我們應當怎樣做需求調研：需求捕獲（下）
我們應當怎樣做需求分析：功能角色分析與用例圖
我們應當怎樣做需求分析：業務流程分析（上）
我們應當怎樣做需求分析：業務流程分析（下）
我們應當怎樣做需求分析：用例說明
我們應當怎樣做需求分析：查詢報表分析
我們應當怎樣做需求分析：子用例與擴展用例
我們應當怎樣做需求分析：行動圖和狀態圖
我們應當怎樣做需求分析：業務領域分析
我們應當怎樣做需求分析：原文分析法
我們應當怎樣做需求分析：領域驅動設計
我們應當怎樣做需求分析：非功能需求
我們應當怎樣做需求確認：需求列表
我們應當怎樣做需求確認：一個需求列表的實例
我們應當怎樣做需求確認：快速原型法
我們應當怎樣做需求確認：需求規格說明書
我們應當怎樣做需求確認：評審與簽字確認會

（續）

我們應當怎樣做需求分析：領域驅動設計