昏睡領域

接續...

[DDD] DDD經驗分享 (上)

 

系統分析階段 (SA)

 

「系統分析階段」主要的工作是對客戶的需求內容，提出解決方案並且分析系統架構。一般會採UML的配置圖、套件圖等等工具，來完成系統分析的工作。最終將設計完畢的解決方案，整理成一份「系統需求規格書」。

 

系統分析階段要做的事很多很雜，甚至可以說是一種無中生有的創造過程。 經驗不足的開發人員進入這個階段，通常會不知所措。這時可以將系統分析階段的工作，切割為不同角度來做分析設計，這也就是所謂的「視圖方法」。透過視圖方法去分析設計整個系統架構，決定系統架構所需要的軟體分層、功能模組....等等。

 

 

同時也以分析設計需求分析階段產出的領域模型，將它封裝、轉化成為系統架構內的功能模組。以這個功能模組為中心，再去分析設計出整個系統架構裡的其他功能模組。當最後將整個系統架構建立完畢，也就完成了「系統分析階段」該做的工作。

 

 

系統分析階段 (SA) – 五視圖

 

這個議題採用的視圖方法為「五視圖」，用它來劃分系統分析階段各種不同面向的分析設計工作。關於五視圖相關的詳細資料，可以參考「軟件架構設計 - 溫昱」這本著作。接下來的說明資料，就透過五視圖方法去分析設計整個系統架構，來完成系統分析階段所要完成的相關設計工作。

 

物理架構

 

物理架構這個面向，是要釐清整個解決方案，所整合的裝置設備與連線方式。並將整理出的資料，採用「UML配置圖」做分析整理的動作。藉由分析設計物理架構的工作，可以描述出整個解決方案所在的實體環境，初步定義整個解決方案的範圍。

 

 

例如上圖是一個門禁系統(Access Control Server)的物理架構資料。圖中描述整個門禁系統解決方案：包含一個Acs伺服器、一個Reader(讀卡機)、還有一個用來存放資料的Database(資料庫)。並且Acs伺服器與讀卡機採用RS485做溝通，而Acs伺服器使用TCP/IP與資料庫做溝通。

 

邏輯架構

 

邏輯架構這個面向，是要來釐清整個解決方案，所應該要開發或是整合的軟體系統。並且針對應該要開發或是整合的軟體系統，完成架構的分析與設計。整個邏輯架構的分析設計，又可以拆分為下列幾個步驟：

 

邏輯架構 - 子系統設計

 

子系統設計這個步驟，是依照物理架構去分析設計，決定要將系統切割成幾個子系統。並將整理出的資料，採用「UML套件圖」做分析整理的動作。藉由分析設計子系統的工作，可以描述出整個解決方案所應該完成的軟體系統，進一步定義整個解決方案的範圍。

 

 

以上圖來說，它是一個門禁系統(Access Control Server)的子系統設計資料。圖中描述整個門禁系統解決方案：Reader(讀卡機)以及Database(資料庫)沒有開發的需求，要採用現有的系統。而Acs伺服器上，則是需要開發一個Access Control Server系統。

 

邏輯架構 - 層級設計

 

層級設計這個步驟，是針對每個子系統做分析設計，決定每個子系統要怎麼去切割軟體分層。這個步驟我通常直接套用常見的三層式架構，就完成層級設計的步驟。至於會選擇三層式架構的原因也很簡單，因為它是在我的團隊內，成員最熟悉的架構。也就是說，應該依照開發團隊或是解決方案的考量，選擇一個適用的層級架構來使用。

 

 

以上圖來說，它就是一個典型的三層式架構。Presentation Layer負責與客戶做互動。Data Access Layer負責與外部系統做互動。Business Layer則是包含了上列兩者之外，屬於系統邏輯的部份。

 

邏輯架構 - 模組設計

 

模組設計這個步驟，是依照「需求分析階段」產出的「領域模型」去做分析設計。首先依照領域模型決定核心功能模組該如何切割設計，並且將核心功能模組分發到軟體分層上。再依照軟體分層缺少的功能模組去做分析設計，整理出核心功能模組之外的功能模組。

 

 

以上圖來說，它是一個門禁系統(Access Control Server)的模組設計資料。它就是很簡單的將需求分析階段產出的領域模型，直接封裝成為Business Layer的核心功能模組。這邊要注意的是，如果解決方案包含的領域模型較為龐大，可以依照功能或是用途來加以分類，將領域模型分割整理成多個功能模組。

 

 

當分析設計出Business Layer的核心功能模組，我們就可以很簡單的在Presentation Layer、Data Access Layer分析設計出相對應的模組。例如：Presentation Layer沒有任何功能模組，我們就加上一個用來與使用者互動的功能模組(Acs.GUI)。而因為系統需要使用RS485與讀卡機做溝通，那就在Data Access Layer加上一個與讀卡機溝通的功能模組(Acs.Messaging)。最後系統有些資料要存到資料庫，那也就在Data Access Layer加入與資料庫做溝通的功能模組(Acs.Data)。

 

邏輯架構 - 架構設計

 

分析設計到了這邊，可以說完成了整個解決方案分割拆解的工作。但光是只有分割拆解，最終得到的設計成果只會是破碎零散的架構設計資料。這時要再搭配架構設計這個步驟，透過這個步驟去分析設計每個功能模組之間的互動流程、互動介面、以及加入關鍵性的架構模式。透過這些設計來整合每個獨立的功能模組，當最後將全部功能模組整合完畢，也就完成了「邏輯架構」該做的工作。

 

 

以上圖來說，它是一個門禁系統(Access Control Server)的架構設計資料。它在核心功能模組(Acs)與溝通功能模組(Acs.Messaging)之間，加入了IoC的設計模式。透過這個IoC的模式，定義了兩個模組之間該如何互動，並且也定義了模組與模組之間的相依性。

 

 

當最後將全部功能模組整合完畢，也可以整理出一份功能模組之間的相依資料。

 

運行架構

 

運行架構這個面向，是要依照整個系統架構去分析設計，決定是否加入多執行緒的設計，並且設計功能模組之間執行緒的通訊模型。

 

 

以上圖來說，它是一個門禁系統(Access Control Server)的運行架構設計資料。它定義了：MessagingClient這個類別收到外部來的多執行緒操作時，它會先將操作封裝為委派(Delegate)交由UI執行緒(SynchronizationContext)去執行。以這樣的方式去設計系統，可以讓除了MessagingClient之外的系統不用去考慮Thread safety相關的設計，因為他們都是處於同一個UI執行緒(SynchronizationContext)下運作。

 

數據架構

 

數據架構這個面向，是要依照整個系統架構去分析設計，決定系統要採用哪種資料庫，並且設計資料庫是否需要備援機制、分散處理的相關議題。也決定系統要使用哪些設定檔，並且設計設定檔佈署位置、以及內容格式等等相關議題。另外如果系統有分散式的設計需求，也可以在這個階段做分析設計，並在有需要的時候回頭修正前幾個階段所做的決定跟設計。

 

開發架構

 

「系統分析階段」最後要做的分析設計，就是決定開發相關的規則。例如：版本管理規則、專案管理規則 (專案名稱、檔案結構)、程式碼撰寫規則 (命名空間、命名規則、例外處理、日誌管理)...等等。這些開發相關的規則，會很大的影響後續產出以及將來維護的成本。能夠儘早做好規範與設計，可以大大降低專案的成本與風險。

 

待續...