摘要

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 的理論支持，使得微服務架構能夠落地，將一個單體應用很好的拆分成各個微服務，能夠快速迭代，快速發佈滿足業務需求。

• 團隊成員寫出來的代碼風格比較統一 每個人知道代碼往哪個地方寫，新人來了，能夠很快上手。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s?__biz=MzI4NjI3MDc1NA==&mid=2247483876&idx=1&sn=5e752da408d06feb6a89b1e364d1cc83&chksm=ebde35a9dca9bcbf075c40751a6042bb7be5099dac6cff2bf51fbb2965417de80b448f5c1965&scene=21#wechat_redirect