# 前言 * 成功的專案 * 有一個豐富的領域模型 * 模型在迭代設計的過程中不斷演變 ## 三個專案的對比 ### 第一個專案 * 簡單實用的web交易系統的第二個版本 * 沒有領域模型 * 沒有公共語言 * 沒有結構化設計 * 挫敗原因 * 業務邏輯 => 需要透過嚴謹地使用領域邏輯設計方法 * 原先第一個專案,變得僵化,變成維護代價高昂的legacy system ### 第二個專案 * 貿易公司的簡單應用程式 * 透過迭代為上一個版本增加新選項 * 有深刻的領域模型並且不斷深化 * 開發人員之間 或 開發人員與領域專家的溝通得到改善 * 設計沒有加重維護負擔,反而變得更容易修改和擴充 ### 第三個專案 * 後來 * 僅重視模型 * 打算以一個領域模型為基礎,建立全球企業系統 * 團隊將開發人員角色獨立出來,導致建模與實作脫節 * 詳細的業務物件設計,不能保證被完整的整合到複雜的應用程式 * 反覆的迭代沒有讓程式碼改進 * 因為開發人員的技術水平參差不齊 * 使用 **非正式的風格和技術體系**來建立**以模型為基礎的物件** * 團隊對專案失去一致的共識,最後不重視模型 ## 複雜度的挑戰 * 真正決定軟體複雜度是**設計方法** * 有些設計因素是技術上的 * 軟體的網路 * 資料庫 * 其他技術方面 * 來自領域本身 / 使用者的活動 / 業務 * 必須在設計中得到解決,否則基礎技術的構想再好也沒用 * 成功的設計 * 大多數的軟體專案,主要焦點是 領域和領域邏輯 * 複雜的領域設計應該以模型為基礎 ## 設計過程與開發過程 * 本書是一本設計書 * 本書假設專案必須遵循 * 迭代開發 * [可以參考敏捷開發和極限程式設計(XP)](#書) * 開發人員與領域專家具有密切的關係 * 消化吸收大量知識,產生一個"反映深層領域知識"並"聚焦於關鍵概念"的模型 * 極限程式設計(XP) * Ken Beck , Ward Cunningham共同提出 * 本書用這個方法作為"討論設計和過程的互動"的基礎 * 強烈反對 預先設計 * 投入"促進溝通" 和 "提高專案快速變更能力" * 持續重構,是一系列小規模的重新設計 * 沒有嚴格設計原則的開發人員,將會建立"難以理解或修改的程式碼" => 違背敏捷的精神 * 避免過度設計 * 走向極端=>不敢做任何深入的設計思考 * 適合設計的感覺很敏銳的開發人員 * 過程試圖改善團隊溝通,模型和設計的選擇可能使溝通更明確或不順暢 ## 本書的結構 ### Part I:運用領域模型 * 提出領域驅動開發的基本目標 * 定義術語 * 提供"用領域模型來驅動溝通和設計"的概述 ### Part II:模型驅動設計的建構區塊 * "將物件導向領域建模"的一些核心的最佳實踐提煉為"一組基本的建構區塊" * 消除 模型與實際執行的軟體間的鴻溝 * 使用這些標準模式 讓團隊可以使用這些術語來討論模型和設計決策 ### Part III:透過重構來加深理解 * 將"建構區塊"組裝為實用的模型 * 有價值的模型需要對領域深入了解,且一步一步得到 * 最初的模型實作透過反覆改進設計(每次團隊對領域有新的理解) * 必須對程式碼進行重構 * 探索是無止境.但不代表是隨機 * 透過Part III 指引"保持正確方向"的建模原則,提供一些進行探索的方法 ### Part IV: 戰略設計 * 討論在複雜系統 或 大型組織以及與外部系統和 遺留系統的互動之中出現的複雜情況 * 系統整體的三條原則 * 上下文(context) * 提煉(distillation) * 大型結構(large-scale structure) * 通常由單一到多個團隊共同制定 * 可以用來保證以較大的規模來實作Part I提出的目標 ## 本書的目標讀者 * 物件導向軟體開發人員 * 軟體專案團隊的大部分成員 * 正在專案上嘗試這些實作的人員 * 已經在專案中累積豐富知識的人員 * 要掌握"物件導向的建模知識" * UML圖 * Java language * 中階軟體開發人員+已經了解物件導向設計 * 可以透過這本書知道在實際的軟體專案中應用"物件建模技術" * 幫助學會用"高階建模和設計技巧" * 高階軟體開發人員 * "綜合框架", 這種"系統性的設計方法"可以幫技術負責人指導團隊保持正確方向 * "明確術語", 有助高階開發人員和他們的同行溝通 * 閱讀方式 * 可從頭到尾閱讀 * 可以任一章的開頭開始閱讀 * 也可以跳躍式閱讀 * 透過閱讀標題和粗體字 * 高階讀者 * 重點閱讀 * Part III - 透過重構來加深理解 * Part IV - 戰略設計 * 分析師 * 透過本書掌握 領域和設計之間的連結 * 利用 戰略設計原則 , 使工作更專注和更有組織 * PM * 透過本書 提高團隊工作效率 和設計出對 業務專家和使用者有幫助的軟體 * 戰略設計決策與團隊組織和工作風格緊密相關 * 推薦所有讀者 * 從Part I 開始閱讀 * 本書核心 * 第2章 - 交流與語言的使用 * 第3章 - 綁定模型與實作 * 第4章 - 分離領域 * 第14章 - 保持模型的完整性 ## 領域驅動團隊 * 團隊 * 可以使用“共同應用領域驅動設計的方法" * 將領域模型 作為專案溝通的核心 * 建立一個"與模型步調一致"的清楚實作 * 所有人了解不同團隊的設計工作之間的關聯 * 將注意力集中在開發"對組織最有價值和最與眾不同的特性" ## 參考 ### 書 * Surviving Object-Oriented Projects , Cockburn 1998 * Extreme Programming Explained , Beck 1999
{"metaMigratedAt":"2023-06-16T16:50:04.387Z","metaMigratedFrom":"Content","title":"前言","breaks":true,"contributors":"[{\"id\":\"6a37dd1b-61d9-41f7-8ca4-24c2b226a6ce\",\"add\":0,\"del\":1},{\"id\":\"ad81c9e6-bf35-4969-8634-848766a833fe\",\"add\":3118,\"del\":308}]"}
    364 views
   Owned this note