輕松學DDD之一：模型驅(qū)動設(shè)計

輕松學DDD之一：模型驅(qū)動設(shè)計

　　我是2012年開始接觸到DDD（領(lǐng)域驅(qū)動設(shè)計）的， 后續(xù)陸陸續(xù)續(xù)研讀過幾遍Eric的大作《領(lǐng)域驅(qū)動設(shè)計：軟件核心復雜性應(yīng)對之道》，也使用DDD重構(gòu)過一個項目。總的感受是DDD的一些概念比較晦澀難懂，很難掌握，因此想寫個系列短文，希望能用通俗易懂的語言幫助大家更輕松更深入地理解DDD。文章很多都是我個人體會和理解，難免有錯誤，希望大家能及時指正，共同提高。
　　本文是系列短文第一篇，介紹ＤＤＤ的起始概念模型驅(qū)動設(shè)計。

1. 軟件開發(fā)方法回顧

　　軟件開發(fā)可以看做是一個把用戶需求轉(zhuǎn)換為可正確運行的程序的過程，其中最關(guān)鍵部分是把用戶需求轉(zhuǎn)換成代碼。我們要學習的DDD實際上就是一種軟件開發(fā)方法，它相比之前的軟件開發(fā)方法，能更好地應(yīng)對軟件的核心復雜度。為了能更好的理解它，我們先回顧下之前的軟件開發(fā)方法及其存在問題。
　　在上世紀６０年代，由于需求簡單，軟件開發(fā)以作坊式開發(fā)為主。但是隨著硬件的飛速發(fā)展，軟件復雜度也迅速激增，終于在７０年引發(fā)了軟件危機。為了應(yīng)對危機，業(yè)界借鑒成熟生產(chǎn)制造管理方法，發(fā)展出以“過程為中心”的瀑布式開發(fā)方法。

1.1 瀑布式開發(fā)

　　瀑布式開發(fā)把整個軟件開發(fā)過程劃分為需求分析、方案設(shè)計、編碼、測試等階段，希望以這種類似工業(yè)流水線的作業(yè)分工方式來控制軟件開發(fā)的風險和成本。

1. 需求分析：通過需求分析我們需要明確用戶想要的功能，會怎么來使用這些功能，通過這些功能能得到什么價值；消除用戶需求中的二義性、相互矛盾的地方；細化各種正常/異常功能場景，驗收準則，性能、可靠性等非功能性約束。
2. 設(shè)計：在設(shè)計階段需要根據(jù)需求分析結(jié)果決定軟件的總體實現(xiàn)方案。在系統(tǒng)設(shè)計階段會確定子系統(tǒng)劃分，進行開發(fā)、運行平臺、數(shù)據(jù)庫等關(guān)鍵技術(shù)選型；在方案設(shè)計階段則會明確模塊劃分，模塊內(nèi)部架構(gòu)，協(xié)作流程，關(guān)鍵算法等。
3. 編碼:根據(jù)設(shè)計完成代碼編寫。
4. 測試:測試軟件是否滿足用戶需求。
   
   　　上圖展示了應(yīng)用瀑布式開發(fā)方法的軟件開發(fā)流程，我們可以看到這種方法可以通過專業(yè)分工和流水作業(yè)來分解復雜度和提升效率，這在在一定程序上緩解了軟件危機。但是與工業(yè)生產(chǎn)不同，軟件需求和開發(fā)過程存在很多不確定因素，因此這種方法在應(yīng)用過程中也發(fā)現(xiàn)了很多問題。
5. 每個需求的各階段由不同的人依次完成，階段之間用文檔傳遞知識，各階段之間缺乏溝通和反饋，錯誤和理解偏差不能及時糾正，往往影響軟件的正確交付。
6. 每個需求輸出各自的分析、設(shè)計文檔，沒有整合。隨著軟件規(guī)模增長，分析和設(shè)計會喪失對軟件整體性的把握，進而影響分析和設(shè)計的全面性和正確性。
7. 由于缺乏反饋，分析、設(shè)計和代碼之間的差異會越來越大，耗費大量人力編寫的分析設(shè)計文檔會逐步失去價值，協(xié)作會越來越困難，軟件也越來越難以按期正確交付。

　　為了解決瀑布式開發(fā)的開發(fā)效率低下、響應(yīng)需求速度慢的問題，輕量級的，更能適應(yīng)變化的敏捷軟件開發(fā)方法被普遍認可并迅速流行起來，極限編程就是其中的一種。

2 極限編程

　　XP主要由13個實踐構(gòu)成，是一種近螺旋式的開發(fā)方法。它將復雜的開發(fā)過程分解為一個個相對比較簡單的小周期；通過積極的交流、反饋以及其它一系列的方法，開發(fā)人員和客戶可以非常清楚開發(fā)進度、變化、待解決的問題和潛在的困難等，并根據(jù)實際情況及時地調(diào)整開發(fā)過程。
　　為了與瀑布式開發(fā)做對比，我們把ＸＰ簡單理解為下圖：

　　通過上圖我們可以看到，XP沒有劃分分析、設(shè)計、編碼和測試等階段，需求可以在一個周期為1~2周的迭代中快速交付。XP之所以能做到快速交付，有如下幾個原因：

1. 客戶、業(yè)務(wù)專家、開發(fā)、測試大家坐在一起完成需求開發(fā)，面對面溝通取代了文檔，節(jié)省了文檔編寫、維護的工作量。
2. 通過簡單設(shè)計、TDD、ATDD、CI等工程實踐保證分析、設(shè)計、編碼、測試之間更快速的反饋和充分的并行化，有效縮短了開發(fā)周期。
3. 通過不斷重構(gòu)代碼來保證代碼更加簡潔，能更好地反應(yīng)軟件的核心復雜度。
4. 通過結(jié)對、代碼集體所有權(quán)、系統(tǒng)隱喻、編碼規(guī)范、完整團隊促進了技能和知識的共享。

　　XP非常反對做預先設(shè)計，需求分析與設(shè)計會被拆分到用戶故事乃至TDD的小步迭代中去做，在每個小迭代中代碼只會根據(jù)當前需求簡單實現(xiàn)；當在后續(xù)迭代過程中發(fā)現(xiàn)代碼難以滿足新需求時，需要通過重構(gòu)來增加代碼對新需求的適應(yīng)性，以便能夠快速實現(xiàn)新需求。這種做法固然能帶來很多好處，但是也存在一些缺陷：

1. 如果軟件復雜度高，需求之間有著復雜的關(guān)聯(lián)，開發(fā)在沒有很理解業(yè)務(wù)邏輯就貿(mào)然開始寫代碼，會帶來非常大的重構(gòu)成本，甚至于需要重寫。
2. 只有代碼承載業(yè)務(wù)共識，維護業(yè)務(wù)共識的成本高，最終導致難以維持業(yè)務(wù)共識。大家交流的共識除了存在于頭腦中外，只存在于代碼中，這對于代碼的業(yè)務(wù)表達力和專家/客戶的代碼理解能力都提出了非常高的要求,最終可能導致大家對于業(yè)務(wù)的理解的差異會越來越大。

3. 模型驅(qū)動設(shè)計

　　為了彌補XP在應(yīng)對軟件核心復雜度的缺陷，eric在2003年提出了一種新的方法，他認為我們需要引入領(lǐng)域模型并圍繞它來做需求分析和軟件設(shè)計，這就是模型驅(qū)動開發(fā)。這一論述有以下幾個要點：

1. 模型是統(tǒng)一的，它反映了領(lǐng)域的核心復雜度，而不是領(lǐng)域內(nèi)每個需求面面俱到的細節(jié)。一些不涉及軟件核心價值且不影響全局的細節(jié)可以在放在迭代中考慮，相關(guān)知識沉淀在代碼中即可，就像XP做的那樣；但是涉及軟件核心價值，或者影響全局的業(yè)務(wù)邏輯需要納入領(lǐng)域模型中做統(tǒng)一細致的分析，并在軟件生命周期內(nèi)不斷地演進精煉。
2. 模型是交流和協(xié)作的中樞。客戶、業(yè)務(wù)專家、開發(fā)、測試等各種角色一起參與構(gòu)建模型的，大家基于共同的模型來做交流和協(xié)作。
3. 模型與代碼是綁定的。代碼修改能方便地同步到模型，模型修改也能方便地同步代碼。這要求模型不只體現(xiàn)問題域的知識和約束，也能體現(xiàn)實現(xiàn)域的知識和約束；涉及業(yè)務(wù)邏輯的代碼需要不斷提煉，剝離技術(shù)實現(xiàn)細節(jié)，以便能很好地表達模型。

　　最后總結(jié)下，模型驅(qū)動設(shè)計通過對軟件核心復雜度的統(tǒng)一建模，解決了瀑布式開發(fā)在需求分析、軟件設(shè)計上的溝通、反饋和知識整合上的缺陷，也解決了XP極簡主義設(shè)計存在的缺陷。
　　文本重點敘述了我們?yōu)槭裁葱枰I(lǐng)域模型，領(lǐng)域模型構(gòu)建需要注意的幾個基本原則，但是具體要怎么來構(gòu)建領(lǐng)域模型呢？請看下一篇《輕松學DD之二：如何高效消化知識》。