最近發現文章老是被竊取，有些平臺舉報了還沒有用。請識別我的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，欲知後事如何，請聽下回分解。
關注【方丈的寺院】，第一時間收到文章的更新，與方丈一起開始技術修行之路
