輕松學(xué)DDD之一：模型驅(qū)動(dòng)設(shè)計(jì)

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

在常寧等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強(qiáng)發(fā)展的系統(tǒng)性、市場(chǎng)前瞻性、產(chǎn)品創(chuàng)新能力，以專(zhuān)注、極致的服務(wù)理念，為客戶(hù)提供網(wǎng)站制作、網(wǎng)站設(shè)計(jì) 網(wǎng)站設(shè)計(jì)制作按需求定制網(wǎng)站,公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),品牌網(wǎng)站設(shè)計(jì),成都營(yíng)銷(xiāo)網(wǎng)站建設(shè),成都外貿(mào)網(wǎng)站制作,常寧網(wǎng)站建設(shè)費(fèi)用合理。

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

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

1.1 瀑布式開(kāi)發(fā)

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

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

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

2 極限編程

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

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

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

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

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

3. 模型驅(qū)動(dòng)設(shè)計(jì)

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

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

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