學習真DDD的最佳路徑

老肖想当外语大佬發表於2024-08-26

本文書接上回《DDD是軟體工程的第一性原理？》，關注公眾號（老肖想當外語大佬）獲取資訊：

  1. 最新文章更新；

  2. DDD框架原始碼（.NET、Java雙平臺）；

  3. 加群暢聊，建模分析、技術實現交流；

  4. 影片和直播在B站。

假DDD的特徵

在開始之前，考慮到目前關於DDD的資料非常多且雜，我們需要具備分辨的能力，確保不被誤導。看過本系列文章的朋友，對我們是如何看待DDD的會有一定的感受，這裡我們列舉一下我們認為的假DDD的特徵，供大家參考：

  1. 堆砌抽象詞彙，讓人不明覺厲的

  2. 說DDD只有高階開發者才適合的

  3. 說DDD很難落地的

  4. 說只有複雜專案才適合的

  5. 說只能憑經驗的

適合人群

首先我們認為“領域驅動設計是一種價值觀”，那麼理解並能夠實踐DDD的前提，認可這種價值觀，既然如此，說明第一步的起點，是沒有門檻的，只要你主觀上認同即可，所以我們認為DDD適合軟體工程工作相關的各個角色來學習和實踐，包括但不限於：

  1. 期望從事軟體領域的在校學生

  2. 各個層級的軟體工程師

  3. 產品經理

首先軟體工程師得懂DDD，這是毋庸置疑的，我隱約有一種感覺，真正的DDD就是軟體工程的唯一正解，不少後端老司機一直苦於隨著時間的推移，系統程式碼快速腐化的問題，而DDD正是對抗這種腐化的底層邏輯，是軟體工程的第一性原理。

對於學生群體，我接觸的案例證明，對於軟體領域的新人，反倒更容易理解和接受DDD，這是因為目前主流的軟體設計指導，很多都指向了與DDD相反的方向，新人因為沒有被這些資訊所誤導，沒了先入為主的思維枷鎖，很自然地容易接受更有收益的軟體設計思想。

軟體工程師最喜歡的產品經理，大機率是懂一些技術的產品經理，而如果對DDD的概念有所理解的產品經理，我相信在需求分析、產品設計、模型設計方面能夠與工程師更容易相互理解並建立共識，大家一定還記得之前文章所說的“擬人化建模溝通法”，在這裡更是能發揮巨大的作用，使得“需求-模型”的一致性得到更好的保障。

學習路徑

下圖展示了一個學習的迴圈迭代，我認為可行幾點如下：

  1. 學概念，透過系列文章、影片，構建基本概念認知

  2. 學實踐，使用DDD框架做程式碼練習

  3. 做驗證，一個教練指導並不斷地實戰體驗，迭代認知和行為

學概念

我們認為DDD的概念是具體的，是容易理解和實踐的，如果你有通讀本系列的前文，那麼一定會有所感受，《老肖的領域驅動設計之路》，其中關鍵的概念觀點包含但不限於：

  • 領域驅動設計是一種價值觀

  • DDD原則

  • 邊界明確是最重要的事

  • 一致性比正確性更重要

  • DDD是軟體工程的第一性原理

  • 系統的複雜度來自元素的數量和元素之間的關係

  • 複雜度守恆定律

  • 擬人化建模溝通法

  • 不要複用

  • 萬能模型之“命令-事件”

  • 如果寫程式碼彆扭，大機率是建模出了問題

學實踐

學實踐，就是不斷地建模設計、程式碼實現，目前我們已經為Java、.NET生態分別提供了DDD戰術框架，基於戰術框架，並配套了工程模板，期望能夠幫助你的團隊在沒有技術負擔的狀態下體驗DDD帶來的優勢和收益，從而增強團隊的DDD認知：

Java：https://github.com/netcorepal/cap4j

.NET: https://github.com/netcorepal/netcorepal-cloud-framework

關於教練

首先教練不是必須的，但一個好的教練，可以讓你大大加速對DDD的認知和應用，教練的核心作用就是：

  1. 引導認知理解

  2. 教授實踐方法

  3. 驗證學習成果

那麼對於一個好教練，我認為最關鍵的就是：能夠判斷決策（需求分析、建模設計、程式碼實現）是否符合DDD價值觀。要做到這點，那麼一個好教練大機率滿足以下特徵：

  1. 對DDD的理解準確

  2. 有實踐的成功經驗

哪裡找一個好教練呢？（廣告時間）在你眼前就有這麼一位，關注我，我在直播間就是扮演教練的角色，歡迎互動交流。

影片與直播：

https://space.bilibili.com/6733407

如何判斷成果

學習過程中，很重要的就是成果的正向反饋，關於DDD的學習，以我的經驗來看，雖然無法給出明確的可量化的指標，但下面幾點可以幫助你從主觀上判斷是否有進展：

  1. 對需求和系統有掌控感了

  2. 需求-模型-程式碼越來越一致了

  3. 寫程式碼感覺絲滑了

  4. 程式碼BUG率有顯著的改善

最後

歡迎交流實踐經驗，持續提高開發者的幸福感。

相關文章