軟件設計：從專業到卓越

很優秀的一本軟件設計書籍，看完後學到很多。

期待看到作者在 ai 時代對本書的內容更新！

強烈推薦，書本知識成體系，從需求分析，到領域建模，到編碼實現整個流程的知識都有涉及，書中知識、案例通俗易懂，也體現出作者對專業知識非同一般的功力。感謝作者寫了這本書，慶幸自己能看到這本書！

我的理解，軟件設計參考計算機架構就很簡單：模塊（輸入模塊，輸出模塊，中央處理器，存儲模塊，調用模塊，電源模塊，等等），聯結關係，接口，……等等，可以替換、迭代，不知道我是理解是不是太簡單了😂

從需求分析到編碼實踐，各個環節的高質量實現都進行了講解，可以用於快速構建如何完成高質量軟件的開發這一問題的知識框架。

我覺得這本書很適合現在的我，之前學習過一些關於簡潔代碼，設計模式，設計原則，重構，測試驅動開發，架構整潔之道的知識，但一直在項目整體開發中應用的不流暢；讀《軟件開發》過程中，有一種互相融會的感覺，使這些單點知識串聯在了一起。例如，項目或需求開發整體流程：需求分析、領域模型設計、由外而內開發，開發中使用合適的接口和契約（利用設計原則和設計模式，進行組件設計與組件之間的協作），測試先行；還例如，將原來零散的知識，內聚起來，向上抽象出一個層次；高質量測試、代碼評審、結對編程、靜態掃描工具，都是爲了提高代碼質量；重構、測試驅動開發、持續集成，都是爲了使軟件持續演進。 讀完之後開發的目標發生了轉換：原來想的是要寫出優質的代碼；現在目標是：爲實現有價值業務，流暢的寫出優質代碼。其中增加了兩個重點：一個是有價值需求，另一個是流暢的寫出（過程中自己感到流暢，更能享受其中）。這個目標與精益思想提到的原則也比較符合。以終爲始（有價值、優質代碼：高質量 可讀性 複用性），流暢的寫出（持續拉動），保證質量和持續演進（演進性）。 書中印象比較深的幾個點： 1.積極探索業務目標，梳理清楚業務流程，可以使用UML圖表示（例如泳道圖），還可以使用具體例子說明；三劍客要儘早達成統一。 2.領域模型是對現實世界的認知，通過捕獲、辨析、演進來構建領域模型有助於更清晰的認識業務目標。領域設計還有助於拆分服務、組件（戰略模式）設計組件（戰術模式）。根據領域還有助於架構分層：接口層，應用層，核心領域層，基礎架構層。 3.領域模型可以使用UML類圖表示，其中空心三角（繼承或泛化），實心三角（實現），空心菱形（聚合-擁有關係，例如學校-老師），實心菱形（組合-強擁有關係，例如學生-學生成績），箭頭（關聯）。 4.設計原則（SOLID）中單一原則、開閉原則、里氏替代原則來指導類的設計；接口隔離、依賴倒置用來指導接口設計，類之間協作的設計。 5.接口的定義可以從需求方出發，這樣的表示需求方需要一個什麼樣的功能來完成事情，這麼設計的好處是需求方更加穩定。接口在提供方一側，表示提供方提供了一個什麼服務，而需求方如果要對接這個服務，最好是搞個適配器，也就是需求方再定義個接口對接外部服務，讓外在的服務不影響內部的功能，這也是整潔架構和六邊形架構中 端口和適配器的思想。 6.通過事件來解耦，使用觀察者模式來解耦。 7.使用從外而內的設計，讓我們更能漸進、流暢的寫出符合目標的代碼，也更易於使用設計原則與設計模式。 8.將原來零散的知識，內聚起來，向上抽象出一個層次。例如：高質量測試、代碼評審、結對編程、靜態掃描工具，都是爲了提高代碼質量；重構、測試驅動開發、持續集成，都是爲了使軟件持續演進。 代碼整潔之道中提到，Michael Feathers說整潔的代碼總是看起來像是某位特別在意它的人寫的。書中提到很多開發實踐中的原則和技巧，負責和用心的態度也很重要。實現有價值的目標，並且在實現這一目標的過程中能享受其中。追尋達成目標需要很多次的實踐。

走馬觀花地看了一遍。作者結合自己數十年的經驗，進行了結構性的總結和輸出，功力深厚，爐火純青。 從需求，設計，開發，測試等軟件全生命週期都有不同側重的闡述，中間涉及到很多細節，涉獵甚廣，如需求金字塔，敏捷開發，整潔架構，DDD，TDD，持續集成。 印象最深的是，代碼是負債還是資產？都不是，是期權。 值得一讀再讀。

需求分析金字塔： 不斷質疑，澄清業務目標 探索業務流程，定義系統功能 設計操作步驟，澄清業務規則 不斷質疑，澄清業務目標 金字塔的第一層是業務目標，這是所有需求分析和討論活動的起點。它致力於搞懂需求獲取階段的核心任務：爲什麼要做這個功能？有時候這個問題還可以反過來：如果不做這個功能，又會怎樣？通過這樣反覆地質疑，往往能把需求背後的思考表達得更爲清晰。 業務目標反映了系統的關鍵利益方（後文統稱爲業務方）對“通過某個業務過程，達成某種業務目標”的期望，這些業務方往往是業務所有者、項目發起人等。 高校後勤部門是這個項目的發起方，但評價其是否成功的核心指標不是“做出了一個系統”，而是“供應商和大學生都有了更高的滿意度”。所以，如何能通過餐品預訂提高滿意度，是這個項目成功的關鍵。（如何提升供應商的滿意度？供應商現在有哪些不夠滿意的地方？） 探索業務流程，定義系統功能 金字塔的第二層旨在在功能概要的粒度上解決系統應該實現什麼功能這個問題，我們稱之爲系統功能或系統責任。但是，不應該直接從業務目標跳到系統功能。在系統之外，一些外部系統、各種業務參與者也參與了業務活動，他們之間的交互共同構成了業務流程。 業務流程的設計顯然需要服務於業務目標。不過，這個設計往往不是簡單地複製現實世界的業務流程。如果發現正在運作的業務流程不合理，就需要探索新的流程方案。因此，這一步的關鍵是“探索”，而不是“描述”。 在業務流程分析清楚之後，系統功能就變得非常清晰了。系統功能就是業務流程中那些和軟件系統有關的功能。例如，前述的發紅包業務的管理員設定紅包發放對象、爲紅包發放對象發紅包等功能，都是在金字塔的這一層進行探索的結果。 業務流程聚焦於業務活動中的主體如何通過一系列業務活動交互，最終達成業務目標。業務交互的主體，也就是參與者，既包含特定的業務角色，如食堂餐品管理員、訂餐人，也包含系統以及外部系統等。系統功能是整個業務流程的一部分。 業務流程的設計可以有多種方法，正向的設計思路比較自然，也就是從同學瀏覽餐品和下單開始，到最終取到餐品結束。從前向後符合人類的思考習慣，不過這不見得是最好的探索與發現方案。經驗表明：正向的思考過程往往容易遺漏關鍵步驟。 EDBA的核心成功要素是：以業務事件爲核心、以終爲始、逆向思考。通過使用EDBA，我們能更容易地發現合理的業務流程，避免遺漏關鍵問題。 業務事件指的是應該被關心的、具有業務價值的事件。基於業務事件進行討論，可以讓需求討論更聚焦、更清晰。這是因爲事件實際發生了，纔是業務流程的真正目標。只要事件沒發生，業務流程就沒有實際意義。相反，事件發生了，那相應的活動反而是可以變通的。 事件優先，由後向前，關注例外，整理推演。方法有效原因： . 如何聚焦討論：業務事件把討論聚焦到結果和實際發生的事情這樣具有確定性的內容上。 ．如何推導：通過逆向思考，讓流程設計在思考的過程中自然浮現。 ．關注異常：異常是導致結果不能達成的一個因素，通過在早期發現異常場景，並予以正確應對，有助於業務流程設計的完整性。 ．延遲決策：業務流程需要我們暫時忘記系統，首先關注事件。系統功能的設計是業務流程設計完成後自然而然就可以推演出來的。 從業務流程到系統需求 系統需求是把“軟件系統”作爲研究對象，定義軟件系統應該做什麼，確定清晰的輸入和輸出。 用例(use case)，顧名思義就是“誰使用系統做什麼”。用例是一種非常有效的用來表達系統需求的方法 業務流程的關注點是業務，系統用例的關注點則要低一個層級，它關注系統。業務流程是分析系統用例時的輸入，基於這兩個業務流程，就可以提取出系統用例。 設計操作步驟，澄清業務規則 金字塔的最下面一層關注的是需求的細節：具體的操作步驟和業務規則。例如，前述的設定紅包發放對象選擇規則等具體的步驟和規則，都是在這一層進行探索的結果。 越往金字塔的下層，細節越多，對於討論的清晰程度的挑戰就越大。當然，越往金字塔的上層，細節雖然越少，但是一旦發生錯誤，影響是最大的。 需求分析的過程，是一個持續探索和發現的過程。這個過程應該遵循金字塔結構，由粗到細，逐層展開。 細節包括兩個重要部分。 ．操作步驟：完成一個任務需要執行的步驟。在我們的案例中，可能需要執行的步驟包括添加食品到購物車、確定取餐時間、選擇取餐點、確認訂單等。 ．業務規則：從業務視角出發的行爲約束。在我們的案例中，可能會約定取餐時間不是任意選擇的，而是以15分鐘爲一個時間單位，且僅覆蓋就餐時間。 領域驅動設計 戰術模式包括三方面內容： ．基本構造塊。領域驅動設計定義了四種構造塊：實體、值對象、領域服務和領域事件。這些構造塊是表達業務概念的基本元素，8.2節將會對它們展開介紹。 ．業務完整性的單元。類和對象的粒度很細。領域驅動設計提出了聚合這個關鍵概念 4，把面向對象設計的粒度從基本構造塊提升到了能真正表達業務意義的層次。基於聚合，領域驅動設計還定義了資源庫和工廠，這兩個模式分別用於管理聚合的存取和創建。8.3節將介紹聚合、資源庫和工廠。 ．分層架構。領域模型不應該“淹沒”在頻繁變化的業務邏輯中。所以，領域驅動設計提出了四層分層架構，特別突出了領域層。在此基礎上，又發展出了一系列變體，包括六邊形架構、整潔架構等。8.4節將介紹分層架構和相關概念，以及如何基於分層架構完成代碼實現。 4領域驅動設計中的聚合和UML中的聚合概念有所不同，請讀者注意區分。 領域驅動設計的戰略模式定義了限界上下文(Bounded Context)，用來表達架構層次上的邊界。顯然，在理想情況下，限界上下文的邊界和子域的邊界應該保持一致。 既然進行了劃分，就需要考慮集成的問題。不同場景下的集成策略有所不同，領域驅動設計總結了一個很全面的集成策略，就是上下文映射。我們將在8.5節和8.6節討論限界上下文和上下文映射的問題。 只有在確實表達了一個相對獨立的業務概念或者業務策略，並且不能簡單地把它歸結到某個既有的業務對象上時，纔是一個真正的領域服務。 由於領域服務不持有數據，所以它自身是沒有狀態的。對軟件實現來說，無狀態是一件好事。 領域事件是一種特殊的值對象，代表從業務專家視角看到的某種重要的事情發生了。事件機制是實現開放 - 封閉原則的重要手段。 在分佈式系統中，領域事件往往還需要一個全局唯一的ID，來實現事件的可追蹤、防止重複等。 緊密相關的對象存在數據一致性問題。聚合用邊界把這些緊密相關的對象放到了一起，保證業務完整性。 (1) 生命週期一致性；(2) 問題域一致性；(3) 儘量小的聚合。 小聚合之間的協作 讀寫模型分離是一種有效的架構策略，可以大幅改善查詢性能。其基本示意圖如圖8.8所示。它把數據的存儲模型分爲讀模型和寫模型。其中，寫模型面向領域模型定義，讀模型面向查詢場景定義。 . 接口層負責處理跟邊界相關的部分。 ．應用層負責處理業務邏輯，業務邏輯是變化較爲頻繁的。 ．領域層負責處理領域模型和領域邏輯，領域模型穩定且接近業務本質，是最爲重要的一層。 ．基礎設施層負責處理數據庫、消息等系統運行時所必須的基礎設施。 如同細胞，限界上下文本質上是一個自治的小世界，它有完備的職責，還有清晰的邊界。

本書對於剛開始進行 ai coding 沒有開發經驗的羣體十分有價值， 系統的對開發原則，思路，最近實踐進行講解， 解答了我在做 ai coding 過程中遇到的一些困惑 1，先開發前端，還是後端， 先做規劃，設計業務邏輯圖，前端框架，在進行開發 2，爲什麼總是開發到一半想重頭開發 在項目開始階段沒有對需求完整的思考清晰 3，ai 說開發完了，一測試好多問題 沒有設計測試用例，和成功標準

非常不錯的一本書，系統性的梳理了高質量的軟件設計如何實踐。這書就像一本大綱，可以依據書中的實踐原則進行拓展學習，值得反覆閱讀理解。