---
# System prepended metadata

title: 第3章 綁定模型與實作

---

# 第3章 綁定模型與實作

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

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

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

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

## 模式：MODEL-DRIVEN DESIGN

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

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

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

## 建模範式和工具支持

![](https://i.imgur.com/1ba70So.jpg)


為了嚴格保證模型與程式設計的一致性，需要使用有建模範式(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 更臻完善