# 前言
* 成功的專案
* 有一個豐富的領域模型
* 模型在迭代設計的過程中不斷演變
## 三個專案的對比
### 第一個專案
* 簡單實用的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}]"}