摘要：最近發(fā)現(xiàn)文章老是被竊取，有些平臺(tái)舉報(bào)了還沒有用。最后不了了之，產(chǎn)品很配合，但是內(nèi)驅(qū)力不強(qiáng)。為什么內(nèi)驅(qū)力不強(qiáng)，因?yàn)榻o他帶來的收益不夠。所以在千個(gè)團(tuán)隊(duì)中實(shí)行可能有千套不同的方案。

最近發(fā)現(xiàn)文章老是被竊取，有些平臺(tái)舉報(bào)了還沒有用。請(qǐng)識(shí)別我的id方丈的寺院。

摘要

DDD領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)，起源于2004年著名建模專家Eric Evans發(fā)表的他最具影響力的著名書籍：Domain-Driven Design –Tackling Complexity in the Heart of Software（中文譯名：領(lǐng)域驅(qū)動(dòng)設(shè)計(jì),之后進(jìn)行了很多迭代和演化，不過大多沒有脫離這本書討論的范圍。因?yàn)镋ric Evans在該書中只是提供了一套原始理論，并沒有提供一套方法論，更別說可落地。所以十幾年，對(duì)于DDD爭論不休，毀譽(yù)參半，喜歡的人覺得他解決了軟件設(shè)計(jì)的復(fù)雜性，不喜歡的人覺得他使得代碼設(shè)計(jì)更加復(fù)雜了。

關(guān)于DDD的理論討論，案例分析的博客也浩如煙海，但是關(guān)于他應(yīng)該如何被引進(jìn)團(tuán)隊(duì)，一步步實(shí)施下去，卻很少見，導(dǎo)致很多人想從0開始的人，不知道如何開始。所以我在寫DDD系列開始前，先寫一下DDD是如何在我們團(tuán)隊(duì)落地，希望能夠?qū)δ阌兴鶈l(fā)。

DDD落地為什么這么難

敏捷迭代，放棄建模

現(xiàn)代互聯(lián)網(wǎng)產(chǎn)研團(tuán)隊(duì)的構(gòu)成一般是市場/運(yùn)營、產(chǎn)品、UI交互、前端、后端、測(cè)試。這些角色的分工是將一個(gè)產(chǎn)品開發(fā)上線的各個(gè)過程拆分出來，然后每個(gè)過程專人負(fù)責(zé)，可以有效提高生產(chǎn)效率，這一套流程是標(biāo)準(zhǔn)的流水線作業(yè)。這樣做的好處毋庸置疑，壞處也很明顯，每個(gè)人只盯著自己那一塊，而忽略整體了。

再來看DDD,領(lǐng)域建模設(shè)計(jì)核心有兩個(gè)

統(tǒng)一語言(軟件的開發(fā)人員/使用人員都使用同一套語言，即對(duì)某個(gè)概念，名詞的認(rèn)知是統(tǒng)一的）

面向領(lǐng)域（以領(lǐng)域去思考問題，而不是模塊）

為了實(shí)現(xiàn)這兩個(gè)核心，需要一個(gè)關(guān)鍵的角色，領(lǐng)域?qū)＜摇Ｋ?fù)責(zé)問題域，和問題解決域，他應(yīng)該通曉研發(fā)的這個(gè)產(chǎn)品需要解決哪些問題，專業(yè)術(shù)語，關(guān)聯(lián)關(guān)系。這個(gè)角色一般團(tuán)隊(duì)是沒有配備的。最接近這個(gè)角色的就是產(chǎn)品了，但實(shí)際上產(chǎn)品并不是干這個(gè)活的。在我們團(tuán)隊(duì)落地過程中，有一段時(shí)間苦于沒有領(lǐng)域?qū)＜遥蚁雙ush產(chǎn)品成為領(lǐng)域?qū)＜遥瑩?dān)當(dāng)起這個(gè)角色。 最后不了了之，產(chǎn)品很配合，但是內(nèi)驅(qū)力不強(qiáng)。為什么內(nèi)驅(qū)力不強(qiáng)，因?yàn)榻o他帶來的收益不夠。

前面已經(jīng)提到敏捷迭代后，每個(gè)角色都是流水線上的螺絲釘，大家都只盯著自己這一塊。對(duì)自己有利的去參與，和自己無關(guān)的不管。

我們先看統(tǒng)一語言與面向領(lǐng)域的好處

因?yàn)榇蠹叶际褂媒y(tǒng)一的一套通用語言，所以溝通成本會(huì)大大減小，不會(huì)在討論A的時(shí)候以為是B。

對(duì)使用產(chǎn)品的用戶有好處，他能在產(chǎn)品不斷更新過程中，有一套統(tǒng)一流暢的體驗(yàn)。用戶不用在每次軟件更新時(shí)都要抱怨為什么之前的一個(gè)數(shù)據(jù)保存后沒有用到了。

面向領(lǐng)域去開發(fā)產(chǎn)品有助于我們深入分析產(chǎn)品的內(nèi)在邏輯，專注于解決當(dāng)前產(chǎn)品的核心問題，而不是冗余的做很多功能模塊，或者幾個(gè)用戶/運(yùn)營反饋的問題就去更改產(chǎn)品邏輯，完了上線后用戶不用，你還在那邊罵用戶朝三暮四，亂提需求。

這些好處粗看一下，其實(shí)對(duì)產(chǎn)品研發(fā)的各個(gè)角色都有意義。但細(xì)看一下呢，溝通成本大大減小，對(duì)于運(yùn)營，產(chǎn)品，UI交互沒啥問題。一個(gè)問題理解的不一致，組織個(gè)會(huì)議，大家好好聊聊就行了。用戶體驗(yàn)一致對(duì)產(chǎn)研團(tuán)隊(duì)有啥好處呢，反正用戶罵的不是我，是客戶和運(yùn)營。深入分析產(chǎn)品的內(nèi)在邏輯有啥用呢？一款產(chǎn)品的成功有很多因素，主要靠上面，我只是一個(gè)小兵，我管不了那么多。有空我多研究研究我的專業(yè)領(lǐng)域，多去看幾篇面試文章。產(chǎn)品黃了，我好跳槽。

因?yàn)楸救耸呛蠖搜邪l(fā)，所以這里不對(duì)其他角色過多展開。只想對(duì)研發(fā)說，你跳槽換個(gè)公司就好了嗎？還是crud boy。還是重復(fù)著寫著很多冗余的功能，冗余的代碼。需求方讓你寫什么，你就寫什么，最后在一天天的加班中喪失了對(duì)代碼的興趣，沒有了夢(mèng)想。 我們都知道改變別人很難，所以先從改變自己開始，先讓自己變優(yōu)秀了，才能影響他人

框架易學(xué)，思想難學(xué)

如果拋開其他角色，單從研發(fā)角度考慮DDD呢。開發(fā)進(jìn)行領(lǐng)域建模，然后遵從康威定律，將軟件架構(gòu)設(shè)計(jì)映射到業(yè)務(wù)模型中。（雖然這個(gè)領(lǐng)域，開發(fā)可能識(shí)別的不對(duì)，暫且忽略這個(gè)問題）

康威（梅爾·康威）定律
任何組織在設(shè)計(jì)一套系統(tǒng)（廣義概念上的系統(tǒng)）時(shí)，所交付的設(shè)計(jì)方案在結(jié)構(gòu)上 都與該組織的溝通結(jié)構(gòu)保持一致。

純研發(fā)實(shí)施DDD,為什么也這么難呢？

沒有標(biāo)準(zhǔn)

DDD是一套思想，一套領(lǐng)域建模設(shè)計(jì)，一套在特定上下文環(huán)境中使用的。所以在1千個(gè)團(tuán)隊(duì)中實(shí)行DDD,可能有1千套不同的方案。一個(gè)實(shí)行DDD多年的人，換了一個(gè)公司，換了一個(gè)團(tuán)隊(duì)，把他原有的那套帶過去，推行下去，一般都不適用。

所以DDD的學(xué)習(xí)和實(shí)踐不像學(xué)習(xí)一個(gè)函數(shù)，API，框架那樣有直接的反饋效果，他需要結(jié)合團(tuán)隊(duì)的實(shí)際情況去實(shí)行，才能達(dá)到效果。

期待DDD解決所有的問題

程序員都是很實(shí)際的，沒有好處的東西是不會(huì)去做的。你必須能夠有效的幫助他提升，他才會(huì)去接受。 比如當(dāng)初有團(tuán)隊(duì)成員提出來，

我們實(shí)行了這一套后，是不是不用加班了，或者加班時(shí)間可以減小。

有測(cè)試提出

實(shí)行這一套后，bug率能降低多少。

研發(fā)需要一個(gè)可以量化的效果，抱歉DDD做不到。沒有哪個(gè)團(tuán)隊(duì)實(shí)行了DDD后，解決了軟件開發(fā)的所有問題。關(guān)于這一點(diǎn)，可以讀一下驅(qū)動(dòng)方法不能改變?nèi)魏问虑?/p>

DDD落地的目標(biāo)

結(jié)合我們團(tuán)隊(duì)的實(shí)際情況，經(jīng)過上面一系列的討論，我們首先確定了我們期待的DDD落地的目標(biāo)

結(jié)合DDD的理論支持，使得微服務(wù)架構(gòu)能夠落地，將一個(gè)單體應(yīng)用很好的拆分成各個(gè)微服務(wù)，能夠快速迭代，快速發(fā)布滿足業(yè)務(wù)需求。

團(tuán)隊(duì)成員寫出來的代碼風(fēng)格比較統(tǒng)一 每個(gè)人知道代碼往哪個(gè)地方寫，新人來了，能夠很快上手。

之后我們就圍繞著這個(gè)目標(biāo)，開始實(shí)行DDD，欲知后事如何，請(qǐng)聽下回分解。

關(guān)注【方丈的寺院】，第一時(shí)間收到文章的更新，與方丈一起開始技術(shù)修行之路