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

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

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

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

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

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

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

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



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

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

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

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



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



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



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

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

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

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

（續(xù)）

我們應當怎樣做需求分析：領(lǐng)域驅(qū)動設(shè)計