經過領域模型的分析後，已經可以看出「物件導向」的雛型了，但領域類別無法直接拿來做程式設計，因為它只是從「使用案例模型」中萃取出來、映射業務領域的概念，而非真正意義上的軟體類別。
一、何謂設計模型
「設計模型」就是用來連結「領域類別」到「軟體類別」的轉換，這就是「物件導向設計階段」的主要任務。
設計階段是整個物件導向分析和設計的關鍵，它將輸出「設計模型」，並綜合各種方法與技巧。設計並沒有一個量化的標準，這代表沒有標準答案，物件導向的設計更像是一門藝術，不過它也是有一定的規律和方法可尋。
二、設計模型總覽
設計模型主要包含：靜態模型和動態模型。
靜態模型又稱為「類別模型」，主要關注系統的「靜態」結構，描述系統包含的類別、類別的名稱、職責、屬性、方法，以及類別與類別之間的關係。
動態模型關注系統的「動態」行為，描述類別本身的一些動作，或者狀態變化，以及類別之間如何配合，才能完成最終的系統功能。
只有結合靜態與動態模型，才能真正描述清楚一個系統。
- 靜態模型：類別的宣告，包括類別、屬性、方法名稱。
- 動態模型：類別的實作，每個方法內部的實作過程。
因為動態模型是描述具體功能的實作過程，看起來會跟「程序導向」的分析方法類似，但它本質上還是「物件導向」，描述的是各個物件之間如何配合與協作。
動態模型必須在靜態模型的基礎上設計，靜態模型的變化也會影響到動態模型。
三、類別模型設計
「類別模型」是整個物件導向設計模型的核心。
進行物件導向類別設計，第一個要解決的問題是：類別從哪裡來？
領域模型中的「領域類別」，便是設計類別中「軟體類別」最好的來源；透過「領域類別」啟發設計最初的「軟體類別」，具有下列幾個明顯的優點：
- 軟體類別來自領域類別，領域類別來自使用案例，使用案例來自客戶；一環扣一環，軟體類別的正確性得到保證，不用擔心主觀臆測所帶來的問題。
- 領域類別到軟體類別的轉換非常簡單，只要掌握基本的物件導向知識就能完成。
- 不需要參考其它系統，不用擔心沒有參考物時無法設計的問題。
(1) 領域類別映射
- 類別篩選
「軟體類別」是軟體系統內部的一個概念，而「領域類別」則是業務領域的概念，並不是每個領域類別最終都會體現在軟體系統中。
- 名稱映射
篩選完成後，將每個領域類別都用一個軟體類別相對應，名稱保持一致即可，別擔心這樣的設計品質不高，目前只是一個開始工作。
- 屬性映射
透過名稱映射得到軟體類別後，接下來就是設計類別的屬性；由於領域類別已經有屬性，因此照搬過來即可。
- 提煉方法
軟體類別的屬性設計完成後，接下就是設計軟體類別的方法；類別方法的設計也是從已有的模型推導出來。
鎖定「使用案例模型」來找到類別方法，其重點就是「找動詞」。
我們之後會以「影像處理軟體」為例，說明如何透過「找動詞」這種技巧找到軟體類別的方法。
(2) 應用設計原則和設計模式
物件導向領域經過幾十年的演進，已經發展出很多成熟的指導方針和方法，以利於評價和規範物件導向設計；其中最具代表性的就是「設計原則」和「設計模式」。
- 設計原則
當提及物件導向領域的設計原則時，其實都是在談論 Robert C Martin 的 「SOLID 原則」。
設計原則也是一個判斷標準，應用設計原則的根本目的是要「保證可擴充性」。
設計模式的本質也是為了提高可擴充性；這也是為什麼透過領域類別映射後，還要繼續應用「設計原則」和「設計模式」的主要原因，根本上都是為了提高設計的可擴充性。
後續將以「影像處理軟體」為例，看看如何應用設計原則。
- 設計模式
相較於設計原則，設計模式更加普及與流行；一般談到設計方法時，都會先想到設計模式。
通常談論設計模式時，其實都是指 GoF (Gang of Four) 所講的設計模式。
設計原則和設計模式是互補關係：設計原則主要規範「類別的定義」，而設計模式主要規範「類別的行為」。
- 設計原則：類別的靜態設計原則。
- 設計模式：類別的動態設計原則。
後續將同樣以「影像處理軟體」為例，說明如何應用設計模式來進行最佳化設計。
(3) 拆分輔助類別
拆分類別的主要目的，是為了使撰寫類別時能夠滿足一些框架或規範的要求；例如常見的 MVC 模式，拆分成 Model、View、Control 三個元素等。
只要將設計出來的類別，按照規範要求，對應拆分即可；這僅是為了滿足框架或者規範的要求，本身並不是設計，而是實作的一個步驟，所以一般都不需要將拆分的輔助類別體現於類別模型中，只在設計程式時拆分即可。
