本文書接上回《DDD建模後寫代碼的正確姿勢》，關注公眾號（老肖想當外語大佬）獲取信息：
- 最新文章更新；
- DDD框架源碼（.NET、Java雙平台）；
- 加羣暢聊，建模分析、技術實現交流；
- 視頻和直播在B站。
前提
本文需要以系列前文的邏輯鏈條和結論為前提，如果沒有閲讀過前文的，可以閲讀合集《老肖的領域驅動設計之路》。
故事背景
在2020年，我所在的研發團隊維護着一個有近十年曆史的SaaS軟件系統，而這個系統又是整個公司的主營業務，用户活躍度非常高。當時我們面臨的最大挑戰就是系統迭代速度遠遠無法應付客户需求，每次迭代發佈都是如履薄冰，我們對系統已經到了完全失控的邊緣。
彼時的我，對於領域驅動設計的認知，並不通透，只是隱約感覺DDD能夠幫助我們走出這個泥潭，我們非常渴求改變，但缺乏確定性的驗證，對於如何改變並走向成功，我們並無把握，甚至我們連如何衡量是否成功，都無法定義出來。在這樣的背景下，我們仍然積極地為作出改變做準備：
- 我們對自己的客户和業務有比較充分的瞭解，技術甚至跟着產品經理一起去拜訪客户
- 我們打造了一套定製的開發框架（也就是現在DDD框架的早期原型），以更準確地用代碼表達業務
常言道，機會是給有準備的人的，很快這個機會就來了。
一個改變一切的目標
2020年9月，在公司CEO的領導下，我們成立了獨立項目組，目標是從零開始，重新打造一套新的SaaS系統，以替換舊的系統，而新系統的核心目標是“保持系統持續的快速迭代”，對你沒看錯，新系統的核心目標，甚至與產品功能、商業指標沒有直接關係。
後來，我們一致認為這個目標，是我們關於軟件工程和領域驅動設計的認知質變的起點，它改變了我們在需求分析、產品設計、系統架構時的核心決策依據，變成“可維護性是最重要的事”，這就使得我們在行進過程中，很多決策都與以往有所不同，甚至是相反的。
可以説，這個目標，改變了一切。
有什麼不同之處
我相信，大家肯定都會有擔憂，把“保持系統持續的快速迭代”作為首要目標，那麼商業層面就不考慮了嗎？其實並不是這樣的，實際上這是一個“既要也要”的要求：
- 要保持系統持續的快速迭代
- 要滿足客户需求
與過去不同的地方是當客户需求與可維護性衝突時，我們怎麼決策：
- 過去：選擇滿足客户
- 現狀：選擇保持可維護性
我們認為這個轉變意味着，整個公司的決策邏輯，從短期拓展到長期，追求更長期的利益價值，願意放棄短期利益，而最考驗團隊的，就是我們是否真的可以拿到“可維護性”這個長期利益。
DDD是正解
如果大家有讀過之前《關於領域驅動設計，大家都理解錯了》一文，應該還記得我們關於複雜度的認知：
- 系統複雜度與元素的數量和元素的關係有關；
- 元素的關係對系統複雜度的影響遠遠大於元素的數量所產生的影響；
因此，我們認為要掌控系統的可維護性，就必須實行分而治之的策略，將複雜度限定在一個個有限的範圍內，這個邏輯正好與領域驅動設計的理念不謀而合：
於是，我們在這個由CEO發起的戰略級項目中，開啓了一段神奇的領域驅動設計落地實踐之旅，為了確保最終結果符合預期，我們甚至建立了一條“不準跨域”軍規，當然本文重點是推導DDD與軟件工程之間的關係，關於“不準跨域”的故事，可以到這裏查看：
【DDD落地的鐵律軍規 - 產品研發都得遵守-嗶哩嗶哩】 https://b23.tv/ukX0uIx
項目的現狀
現今已經到了2024年的後半年，也就是説上述的項目，已經經歷了大約四年發展和迭代，中途我本人也因為個人的一些因素離開了團隊，最近我特地向朋友瞭解項目的近況，他也是項目的核心架構師之一，得到了肯定的答覆：
- 項目目前仍保持較好的可維護性，迭代沒有陷入過去那種困局
- 中間也經歷過做一些不太符合長期利益的需求
- 可維護性是靠團隊不斷堅守業務、模型、代碼邊界清晰和一致性獲得的
- 業務、模型邊界清晰不意味着與滿足需求對立
再看看目前我自己所帶領的團隊，經歷半年時間把一個項目從失控邊緣拯救回來，發展到目前與業務保持一致，迭代維護不再有畏懼和負擔感的狀態。種種跡象都表明，領域驅動設計是至關重要的。
第一性原理
對於確定不迭代的系統，意味着可維護性的意義就不那麼重要了，對於科研類或者其它領域的軟件，可能要解決的更重要的問題是“技術難題”等其它維度的問題。
迴歸到主題，我一直在思考“DDD是軟件工程的第一性原理？”這個問題，過往的這些經歷，越發讓我堅信這一點，但如果讓結論更加嚴謹，需要限定條件如下：
- 軟件系統是長期迭代的
- 軟件系統是業務向的系統
在這樣的背景下，那麼標題的答案是肯定的：_DDD是軟件工程的第一性原理！_
後續
如果你認同本文的推導邏輯和觀點，那麼我相信你一定會期望瞭解如何掌握DDD，下一期，我們將講述學習和實踐DDD的最佳路徑。
