昏睡領域

接續...

[DDD] DDD經驗分享 (中)

 

系統設計階段 (SD)

 

「系統設計階段」主要的工作是對設計完成的系統架構，做每個功能模組的物件設計。一般會採UML的「類別圖」、「循序圖」等等工具，來完成系統設計的工作。最終將設計完畢的解決方案，整理成一份「系統設計規格書」。如果說需求分析階段是建立骨架，那麼系統設計階段就是填補血肉的工作。

 

從系統分析階段要跨到系統設計階段，說真的也是一種無中生有的創造過程。只不過不同的是，系統分析階段是整個系統架構無中生有，系統設計階段是針對模組物件要無中生有。這時候領域模型就發揮了指引的功能。透過分析設計領域模型的方式，可以有限度的將領域模型轉換為核心的功能模組物件。以這個功能模組為基礎去分析設計，就能設計出其他系統架構內的功能模組。當把所有功能模組都設計完畢，也就完成了整個「系統設計階段」該做的工作。

 

 

系統設計階段 (SD) – 模組設計

 

「領域驅動開發」定義了一組模式用來指引開發人員，將領域模型轉換為的功能模組物件。關於這些模式的詳細資料，可以參考「Domain Driven Design - Eric Evans」這本著作。通過這些模式可以將需求分析階段產出的領域模型，轉換為如下圖的功能模組物件。

 

 

經過轉換領域模型得到的這個功能模組物件，不會是一個獨立的工作項目。這個功能模組物件也要與Use Cases、Prototype等等資料做整合，必須要可以通過功能模組物件來完整實現，與客戶訪談所記錄下來Use Cases、Prototype這些資料。例如說，某個Use Case內記錄了客戶想要「設定使用者，通過哪個門」，那在功能模組物件上就要可以透過物件模型，去找到這樣的抽象描述：「使用者物件擁有卡片ID屬性。將這個卡片ID屬性，透過讀卡機物件對讀卡機硬體做卡片可通行設定。當讀卡機硬體感應到可通行的卡片，就會把門打開讓使用者通過。」。當功能模組物件可以通過所有Use Case的檢驗，也就驗證了功能模組物件的正確性。開發人員就可以安心的以這個功能模組物件為基礎，去分析設計出其他系統架構內的功能模組。當把所有功能模組都設計完畢，也就完成了整個「系統設計階段」該做的工作。

 

系統實做階段 (Implement)

 

「系統實做階段」主要的工作是將完成的系統架構設計，變成實際執行的程式碼。最終將實做完畢的解決方案，交付給客戶使用。

 

基本上，只要前面幾個階段做的好，系統實做階段就只是單純的按圖施工。但是實際上常常會遇到問題而碰壁，例如實做的平台、引用的框架不支援某某功能。這時候就要回頭修正前幾個階段所做的決定跟設計，將問題點一一解決。最終就能完成整個軟體、交付給客戶等驗收了。

 

 

但要特別說明的是，產出解決方案是為客戶服務。但一個軟體系統除了為客戶服務之外，它也需要為開發人員服務。因為相關的研究顯示，軟體系統的生命週期，在開發完畢後的維護階段，佔了整個軟體生命週期的最大部份，而負責維護的人就是開發人員。如果能夠產出高品質程式碼，就可以大幅降低後續維護或是修改所需要的人力成本、減少開發人員的工作量。

 

 

結論

 

「DDD經驗分享」這個議題到這邊，相信大家對於這兩句：軟體開發流程定義做甚麼、領域驅動開發定義怎麼做，有一定的認知。並且知道了讓軟體系統的開發，不是無中生有的創造過程，而是經過層層手續跟工法生產的成果。但是就算知道了做甚麼以及怎麼做，最重要的還是需要動手去做。只有親自動手下去做才會知道實做上的眉眉角角，也才能真正掌握這些開發技術。

 

參考書籍

 

最後，DDD經驗分享這個議題，還有很多內容細節沒有說明。對這些開發技術有興趣的開發人員，可以參考下列幾本的書籍，相信它們能對開發人員有所幫助。

 

- 英文書籍 : Domain Driven Design - Eric Evans
- 繁體書籍 : 寫給SA的UML/MDA實務手冊 - 邱郁惠
- 簡體書籍 : 軟件架構設計 - 溫昱