咱們團隊是如何落地DDD的(1)

最近發現文章總是被竊取，有些平臺舉報了尚未用。請識別個人id方丈的寺院。

摘要

DDD領域驅動設計，起源於2004年著名建模專家Eric Evans發表的他最具影響力的著名書籍：Domain-Driven Design –Tackling Complexity in the Heart of Software（中文譯名：領域驅動設計,以後進行了不少迭代和演化，不過大多沒有脫離這本書討論的範圍。由於Eric Evans在該書中只是提供了一套原始理論，並無提供一套方法論，更別說可落地。因此十幾年，對於DDD爭論不休，譭譽參半，喜歡的人以爲他解決了軟件設計的複雜性，不喜歡的人以爲他使得代碼設計更加複雜了。

關於DDD的理論討論，案例分析的博客也浩如煙海，可是關於他應該如何被引進團隊，一步步實施下去，卻不多見，致使不少人想從0開始的人，不知道如何開始。因此我在寫DDD系列開始前，先寫一下DDD是如何在咱們團隊落地，但願可以對你有所啓發。

DDD落地爲何這麼難

敏捷迭代，放棄建模

現代互聯網產研團隊的構成通常是市場/運營、產品、UI交互、前端、後端、測試。這些角色的分工是將一個產品開發上線的各個過程拆分出來，而後每一個過程專人負責，能夠有效提升生產效率，這一套流程是標準的流水線做業。這樣作的好處毋庸置疑，壞處也很明顯，每一個人只盯着本身那一塊，而忽略總體了。

再來看DDD,領域建模設計核心有兩個

• 統一語言(軟件的開發人員/使用人員都使用同一套語言，即對某個概念，名詞的認知是統一的）
• 面向領域（以領域去思考問題，而不是模塊）

爲了實現這兩個核心，須要一個關鍵的角色，領域專家。他負責問題域，和問題解決域，他應該通曉研發的這個產品須要解決哪些問題，專業術語，關聯關係。這個角色通常團隊是沒有配備的。最接近這個角色的就是產品了，但實際上產品並非幹這個活的。在咱們團隊落地過程當中，有一段時間苦於沒有領域專家，我想push產品成爲領域專家，擔當起這個角色。 最後不了了之，產品很配合，可是內驅力不強。爲何內驅力不強，由於給他帶來的收益不夠。

前面已經提到敏捷迭代後，每一個角色都是流水線上的螺絲釘，你們都只盯着本身這一塊。對本身有利的去參與，和本身無關的無論。

咱們先看統一語言與面向領域的好處

• 由於你們都使用統一的一套通用語言，因此溝通成本會大大減少，不會在討論A的時候覺得是B。
• 對使用產品的用戶有好處，他能在產品不斷更新過程當中，有一套統一流暢的體驗。用戶不用在每次軟件更新時都要抱怨爲何以前的一個數據保存後沒有用到了。
• 面向領域去開發產品有助於咱們深刻分析產品的內在邏輯，專一於解決當前產品的核心問題，而不是冗餘的作不少功能模塊，或者幾個用戶/運營反饋的問題就去更改產品邏輯，完了上線後用戶不用，你還在那邊罵用戶朝秦暮楚，亂提需求。

這些好處粗看一下，其實對產品研發的各個角色都有意義。但細看一下呢，溝通成本大大減少，對於運營，產品，UI交互沒啥問題。一個問題理解的不一致，組織個會議，你們好好聊聊就好了。用戶體驗一致對產研團隊有啥好處呢，反正用戶罵的不是我，是客戶和運營。深刻分析產品的內在邏輯有啥用呢？一款產品的成功有不少因素，主要靠上面，我只是一個小兵，我管不了那麼多。有空我多研究研究個人專業領域，多去看幾篇面試文章。產品黃了，我好跳槽。

由於本人是後端研發，因此這裏不對其餘角色過多展開。只想對研發說，你跳槽換個公司就行了嗎？仍是crud boy。仍是重複着寫着不少冗餘的功能，冗餘的代碼。需求方讓你寫什麼，你就寫什麼，最後在一每天的加班中喪失了對代碼的興趣，沒有了夢想。
咱們都知道改變別人很難，因此先從改變本身開始，先讓本身變優秀了，才能影響他人

框架易學，思想難學

若是拋開其餘角色，單從研發角度考慮DDD呢。開發進行領域建模，而後聽從康威定律，將軟件架構設計映射到業務模型中。（雖然這個領域，開發可能識別的不對，暫且忽略這個問題）

康威（梅爾·康威）定律
任何組織在設計一套系統（廣義概念上的系統）時，所交付的設計方案在結構上 都與該組織的溝通結構保持一致。

純研發實施DDD,爲何也這麼難呢？

沒有標準

DDD是一套思想，一套領域建模設計，一套在特定上下文環境中使用的。因此在1千個團隊中實行DDD,可能有1千套不一樣的方案。一個實行DDD多年的人，換了一個公司，換了一個團隊，把他原有的那套帶過去，推行下去，通常都不適用。

因此DDD的學習和實踐不像學習一個函數，API，框架那樣有直接的反饋效果，他須要結合團隊的實際狀況去實行，才能達到效果。

期待DDD解決全部的問題

程序員都是很實際的，沒有好處的東西是不會去作的。你必須可以有效的幫助他提高，他纔會去接受。
好比當初有團隊成員提出來，

咱們實行了這一套後，是否是不用加班了，或者加班時間能夠減少。

有測試提出

實行這一套後，bug率能下降多少。

研發須要一個能夠量化的效果，抱歉DDD作不到。沒有哪一個團隊實行了DDD後，解決了軟件開發的全部問題。關於這一點，能夠讀一下驅動方法不能改變任何事情

DDD落地的目標

結合咱們團隊的實際狀況，通過上面一系列的討論，咱們首先肯定了咱們期待的DDD落地的目標

• 結合DDD的理論支持，使得微服務架構可以落地，將一個單體應用很好的拆分紅各個微服務，可以快速迭代，快速發佈知足業務需求。
• 團隊成員寫出來的代碼風格比較統一
  每一個人知道代碼往哪一個地方寫，新人來了，可以很快上手。

以後咱們就圍繞着這個目標，開始實行DDD，欲知後事如何，請聽下回分解。

關注【方丈的寺院】，第一時間收到文章的更新，與方丈一塊兒開始技術修行之路