DDD 落地的思考 -- 一切需求從領域出發
一、背景
這個點是在平時做需求的時候想到的，當然也是區別於常規的業務開發的思維角度，從標題上看像是有點虛誇的意思，但是如果認可 DDD 可以解決複雜度問題的話，不妨先讀一讀文中的內容。
二、業務背景
這裏將業務背景分爲多個場景，方便分別討論
2.1 從 0-1 構建一些新系統
一般而言從 0 到 1 構建的新系統並不是特別難的事情，重點是新系統背後代表的相關領域活動能否被識別到，新系統意味着新的需求或者相關領域能力的構建，所以從領域的角度來講是非常容易識別和實踐的。
2.2 從 1 到 N 進行迭代
大多數情況下很少會遇到從 0-1 構建新系統的機會，所以從 1 到 N 可能更有技術挑戰，一般而言不談領域，採用常規方法進行迭代也不是不可以，只是不一定能全面的感知到整個業務領域的變化。所以從 1 到 N 之間的演進用領域驅動的方法去分析可能更好。
2.3 從 N 到 0 進行維護
這種場景其實不是很常見，因爲很多微服務系統在業務萎縮到一定階段或者即將完成其使命的時候就到了要下線的時候了，所以從 N 到 0 維護系統的話，常規的視角看可能就是換個系統，或者業務沒有了，或者不重要了，在僵而不死的系統中進行迭代維護其實也比較難，可能就破罐子破摔了。但是另外一方面此類場景正好印證了領域隨着業務變化而隨時消亡或者被新領域替代的規律。從企業的角度來說此類系統更是極爲雞肋，但是也沒有更好的方法去做系統功能的收縮合並，所以成本問題也是需要考慮的。
2.4 技術側改造需求
有時候技術側改造的需求可能並沒有意識到是技術領域的變化，當然從技術的角度來說不是特別關心是不是從領域出發，但是實際上是對技術領域相關的內容做了更新來適應業務的需求。
三、出發點
如果一切需求都是從領域出發的話，那必然要劃分多個上下文和領域，不同的部分由不同的團隊和系統負責，對應實現交叉和協同。但是一個大的公司或者一個大的範圍領域應該如何識別業務需求，尋找突破口呢？
3.1 業務流程
每次需求的變化都會導致業務流程出現新增，修改，上線，和下線，但是很多時候這方面的東西不論是產品還是技術都沒有很好的把控不同系統的業務流程，類似於沒有文檔化，沒有可視化，這方面的東西也比較雜，亂，多。所以需求一旦有變化或者提出新的流程的話那最好需要跟中下業務流程。這裏其實也考研文檔能力和文檔管理系統的水平，畫業務流程有如下幾個工具可以使用到如 Plantuml,ProcessOn 的流程圖，泳道圖等。當然不太推薦思維導圖。如何管理業務流程，個人覺得可以進行分層管控，如下圖：
3.2 模型變更
並不是每個需求都需要業務流程變更，當然也並不是每個需求都可能存在模型變更。這裏強調的是模型的變更必然意味着系統的變更，同時也是業務需求的變更。從模型上入手去管理需求，結合領域上下文的話則可以方便的做到將需求管理域領域變化進行結合。這裏的模型不僅包括數據庫模型，業務模型，也包括接口模型和接口參數模型。有時候某個領域的接口或者模型參數變化必然會與另外一個系統或者領域發生聯繫，所以模型變更如果管理好版本的話，可以反推需求的清晰度，需求的迭代過程等等。
3.3 技術影響
有時候某些需求是技術側推動的，但是技術上的變化其實對於當前的業務流程和功能可能沒有多少影響，比如技術改造，升級。但是這隱含了一個領域，就是技術領域，在技術領域中有哪些子領域可以支持業務發展，保障持續性服務。所以在不同系統中的技術側改造其實也是從技術領域來幫助業務領域更好的實現其價值，所以也印證了技術是爲業務服務的。那麼在技術影響方面上來說，新系統或者已有的系統改造都必然摻雜着技術因素，所以門檻會稍微高一點，產品，運營可能不需要懂太多的技術知識，所以從技術上的角度來看技術改造類的需求的出發點一定是技術領域中的某些部分。不同公司的技術領域中的東西大同小異，但是要發揮其能動性還需要領導層的推動和成本投入，比如技術文化氛圍，技術棧儲備和選型，技術人才的發揮，技術積累，複用，創新等。
四、落地限制
4.1 文檔缺乏
很多公司都缺乏文檔，當然我指的是領域文檔，模型文檔，接口文檔，流程文檔等。一方面是不夠完善全面，另外一方面也是比較零散。從產品的角度來看他們產出的文檔在一個地方，技術產出的文檔在一個地方，另外也有部門牆的存在，所以導致文檔其實沒有發揮到最大的價值。
4.2 沒有統一認知
沒有統一的認知是領域需求落地的最大障礙之一，並不是每個公司每個部門都會認可領域驅動設計，尤其是領導層面，從領導層面來看他們可能並不太關心你用什麼技術，怎麼表達業務，怎麼實現。所以如果需要達到一切需求從領域出發的效果可能需要自上而下的統一認知。
4.3 平臺工具有限
另外一個限制是平臺工具其實沒有特別好用的，個人認爲市面上幾乎所有文檔工具，技術平臺都無法完整的滿足企業軟件開發需求，所以用領域的角度來管理需求變更的話需要從文檔軟件工具和效率平臺工具去入手。比如在企業文檔領域有 QQ，微信，飛書，語雀，confluence 等。產品文檔工具藍湖，processon 等等。軟件開發工具更多了，但是不同公司的規模其實選用的工具體系都不一樣，我要表達的意思是這些文檔產出的內容是否可以進行集成比如按項目角度去集成管理等等。
4.4 誤區
昨天想這篇文章的內容時需要特別說明的一點是，一切需求從領域出發並不是非要按照領域驅動設計的那樣去設計重構軟件，有些簡單的需求其實並不需要複雜的領域驅動設計架構來實現。所以核心的思想是希望將軟件開發的思維從常規的方式轉爲從領域的角度去思考，構建基於業務領域的全景地圖，每塊內容都有完整的子地圖及其發展演進過程。
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/quODSDKycA0u9-cuC0bcEA