# 第3章 綁定模型與實作

## Intro
作者舉了 2 個先前在業界工作遇到的 2 種不同開發流程交織而成的狀況

- 使用 JAVA 來替換先前老舊 C++ 應用程式
- 老舊的程式版本沒有根據對象進行建模
- 僅是將功能一個一個堆疊上去
- 沒有使用泛化 or 抽象...等方式
- 技術分析人員與業務專家反覆討論後，製作出了模型
- 開發人員並未參與模型建模
- 模型中的功能間**有著錯綜複雜關係**
- 開發人員無法將該關係轉換成可儲存、可取出且具有事務完整性的單元
- 模型應該清晰，劃分明確的邊界
- 基於模型是 **“正確”** 的 - 是技術分析人員與業務專家反覆溝通得來。開發人員最終得出以下結論
- 無法將模型中的概念對象作為設計的基礎
- 開發人員直接從程式開發角度去實作設計
- 充其量可能會用到與模型中有定義的名稱、相關屬性

但上述 2 種開發方式，最終完成的產品卻走向相同狀態

- 都實現了系統功能
- 但程式複雜，難以理解，進而難以維護
- 閱讀代碼無法深入了解系統目的

## 模式：MODEL-DRIVEN DESIGN

#### 作者提出有問題的狀況

- 未有領域模型
- 無法利用前面提到的做法獲得好處
- 知識消化
- 通用語言
- 若其軟體涉及領域越來越複雜，會使整體專案陷入泥沼
- 光搞懂舊程式在幹嘛就需要花費大量成本
- 更別提需要修改某一功能
- 領域模型並未是所有相關人員參與建立
- 程式碼與模型並未緊密連結
- 在初期階段，模型或許還能當作探索工具
- 隨著專案越往後期，這些模型可能還會造成誤導
- 因程式碼與模型並未相互對應
- 模型與程式設計間連結的分離，往往是有意為之的選擇
- 提倡使用完全脫離程式設計的分析模型
- 僅針對該領域進行分析
- 不考慮在程式中的意義
- 該分析模型中的領域知識，在開始開發後，大部分就會被遺棄
- 無法滿足程式開發需求，開發人員需要重新進行抽象
- 模型內的關係太過複雜
- 模型內的定義太過虛幻
- 程式碼的設計與分析模型開始脫鉤
- 實作過程中發現更多知識點與細節
- 而因為分離了模型設計，導致分析模型與程式碼產生分歧

#### 小結
- 如果整個程式設計 or 核心沒有跟領域模型相呼應
- 該模型就是沒有價值的
- 其軟體的正確性也會受到懷疑
- 模型與設計中的複雜關係也會難以讓人理解
- 若之後更改設計，更難以進行維護
- 分析與設計若分歧後，之後各自所獲得的知識將難以互相共享
- MODEL-DRIVEN DESIGN
- 追求同時滿足分析模型與程式設計的單一模型
- 程式中的每個物件都真實反映了模型相對應概念
- 建模與程式設計會結合成一個統一的迭代過程
- 若模型對於程式實作不太實用：重新設計模型
- 若模型無法真實反映領域概念：重新設計模型
- 搭配 UBIQUITOUS LANGUAGE
- 使用可以支援建模範式的開發工具、語言

## 建模範式和工具支持


為了嚴格保證模型與程式設計的一致性，需要使用有建模範式(Modeling Paradigm)的軟體工具
- 物件導向程式語言
- 建模範式為基礎
- 提供模型建構實作方式，能夠直接建立物件模型中的物件與其關係
- 物件真實存在於記憶體中
- 可以與其他物件相互關聯
- 可被組織成類別
- 各物件都要能接收資料、處理資料並將資料傳給其他物件
- 像 C 語言這種類型的過程語言，則不適用於 MODEL-DRIVEN-DESIGN 上
- 程式設計師告訴電腦一連串要執行的步驟
- 程式本身
- 其程式碼本身並無實質上的意義

## 範例 - 從過程設計到 MODEL-DRIVEN-DESIGN
> 第一章中提到的 pcb，其電路板上的 Net 在佈線時有大量的條件去限制佈線方式
> 而每個 NET 本身都擁有各自的佈線規則
> 工程師會將有相同規則的 Net 將其分組，同組 Net 共用相同規則，最終構成匯流排 Bus

- 過程設計
- 工程師針對規則去編寫腳本分析佈線工具內的資料檔案，之後將規則插入該檔案中
- 透過嚴格的命名方式，讓該資料檔案內的相同規則內容可以被排列在一起
- 初期不多的腳本內容確實可以達成預期效果
- 但當後期有成千上萬的腳本時，當排線相關規則改變時就會遇到大麻煩
- MODEL-DESIGN-DRIVEN
- 後續易於擴展 / 設定組合限制條件 / 增強原先功能
- 在測試方面也提供了便利，可以針對各元件進行單元測試

## 為什麼模型對使用者重要
- IE 瀏覽器的我的最愛書籤實作方式認知差異
- 系統面
- 一個包含 URL 的檔案
- 檔案名稱儲存在我的最愛列表中
- 若命名檔案時使用特殊字元則無法成功命名，會出現提示訊息
- 檔案名稱不能包含特殊字元
- 使用者
- 書籤命名方式應該是自由的
- 檔案名稱是指什麼?我不是在進行加入書籤的動作嗎?
- 調整模型，讓彼此的認知相同
- 讓彼此認知相同，減少因為認知差異導致體驗不佳、誤會發生機會
- 藉由重新審視模型 / 調整模型，將軟體的主旨可以更加明確的展示給使用者
- 使用者有更多機會去挖掘軟體的使用方式
- 使軟體的行為合乎情理，前後一致

## HANDS-ON-MODELER

- 領域模型需要領域業務專家、技術分析人員、開發人員共同建模、維護
- 若將此行為跟某部分成員脫鉤，則後續模型在使用上可能就會建建派不上用場
- 程式碼與領域模型有強烈連結性，修改程式碼可能就是修改模型
- 使用有支援模型範式 (Ｍodeling Paradigm) 的開發語言 - 物件導向語言
- C#、Java...
- 相關人員都需要對模型有一定程度的負責
- 編寫程式碼的人，讓程式碼與模型保持高度關聯性
- 參與建模的技術人員，需要花時間了解程式碼
- 修改程式碼的人，需要學會用程式碼解釋模型
- 參與其他工作的人都需有意識地透過通用語言跟開發人員溝通
- 彼此交換 Modal 的想法，讓 Modal 更臻完善