資訊專欄INFORMATION COLUMN
摘要：最近發現文章老是被竊取，有些平臺舉報了還沒有用。最后不了了之，產品很配合，但是內驅力不強。為什么內驅力不強，因為給他帶來的收益不夠。所以在千個團隊中實行可能有千套不同的方案。
最近發現文章老是被竊取，有些平臺舉報了還沒有用。請識別我的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，欲知后事如何，請聽下回分解。
關注【方丈的寺院】，第一時間收到文章的更新，與方丈一起開始技術修行之路
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/6729.html
摘要：的演進按照上述的說明，在一個單體服務中，隨著業務的不斷迭代，可能會發生什么嚴重的問題。個人認為造成這個原因的主要原因還是在于長期以來的這種模式只有縱向切分導致。摘要 mvc是一種軟件設計模式，最早由Trygve Reenskaug在1978年提出，他有效的解決了表示層，控制器層，邏輯層的代碼混合在一起的問題，很好的做到了職責分離。但是在實際的編碼實踐過程中，你會發現這個模式隨著業務的擴展，變...
摘要：中的事件的一個，我暫且理解為一個中的和這兩個屬性已經在框架中直接掛載在了對象上，歸功于曾老師。 CQRS是啥？DDD又是啥？ 這兩個概念其實沒什么神秘的，當然此文章中的這兩個概念以曾老師的課程為準（關于CQRS和DDD的標準概念，google上已經很多了，不再贅述。） DDD(Domain Driven Design)，領域驅動設計開發。 DDD和OOP有什么同嗎？其實就我個人經驗來說...
摘要：針對這樣的客戶，靈雀云除了提供容器云，還會基于容器云提供工具鏈和咨詢服務。第三階段，是上云原生。靈雀云建議，先做邊緣應用系統的微服務化，或者單體直接應用上云。靈雀云會幫助客戶成立專家組，實踐敏捷活動和工具鏈一整套的解決方案。 今天很榮幸能在這里跟大家一起分享下靈雀云在金融行業的云原生解決方案。 CNCF的云原生核心理念是快速交付業務價值，而云原生時代，主要由三駕馬車驅動：容器、DevO...
摘要：馬蜂窩旅游歷經幾十個版本的開發迭代，在啟動流程上積累了一定的技術債務。我們定義啟動廣告曝光率啟動廣告曝光啟動廣告加載。 增長、活躍、留存是移動 App 的常見核心指標，直接反映一款 App 甚至一個互聯網公司運行的健康程度和發展動能。啟動流程的體驗決定了用戶的第一印象，在一定程度上影響了用戶活躍度和留存率。因此，確保啟動流程的良好體驗至關重要。 「馬蜂窩旅游」App 是馬蜂窩為用戶提供...
閱讀 3768·2021-08-30 09:47
閱讀 3690·2019-08-30 15:56
閱讀 677·2019-08-30 14:18
閱讀 698·2019-08-29 16:17
閱讀 2065·2019-08-29 11:07
閱讀 642·2019-08-26 13:53
閱讀 3443·2019-08-26 10:26
閱讀 2491·2019-08-23 18:30
