前言

上一篇談到戰略資訊系統的分層設計，要如何進行呢? 中大型企業一般會請管理顧問公司或IBM/HP...等資訊服務公司，協助規劃，辦理一些共識營的活動，擘劃企業願景、凝聚共識，進而展開至各事業群，訂定未來方向，這種由上而下(Top Down)的方式，可以確保企業目標可以藉由各部門的分工與合作，順利達成。領域驅動設計分為戰略與戰術設計，其中戰略設計也是類似的方式，事件風暴(Event Storming)就是與領域專家、使用者與開發團隊凝聚共識的方法。

系統分析方法論的演進

領域驅動設計並不是橫空出世，而是經由過去幾十年的逐步演化而成的，它是一種系統分析與設計的方法論，現在系統開發人員幾乎不太注重系統分析技能了，學校也不注重了，大部分人都是畫幾張『使用案例圖』(Use Case Diagram)、『類別圖』(Class Diagram)交差了事，對於複雜的流程，了不起再補張『順序圖』(Sequence Diagram)，這樣的作法見樹不見林，只注重系統設計，不管系統分析，如此進行中大型系統的開發，幾乎註定要失敗。

圖一. 使用案例圖(Use Case Diagram)，圖形來源：維基百科

圖二. 類別圖(Class Diagram)，圖形來源：ResearchGate

圖三. 順序圖(Sequence Diagram)，圖形來源：Zim - A Desktop Wiki

隨著中台架構/領域驅動設計的聲量變大，筆者很高興熱潮又擺盪回來了，大家又開始討論系統分析方法論了，領域驅動設計可以搭配各種開發框架及設計模式，使開發者願意更進一步的將分析與設計做好，形成『分析/設計/開發』一貫的流程，它不像UML，只提供圖形工具，參見下圖，領域驅動設計則有一套完整的方法論(Methodology)，也就是遵循步驟，就可以順利的將系統開發出來。當然不保證功能一定會符合使用者的期望，因為那是屬於分析技巧與甲乙雙方認知的問題。

圖四. UML圖形工具，圖形來源：維基百科

筆者一路看著系統分析方法論的進展，覺得非常有意思，從『結構化分析與設計』(俗稱DFD)、UML/RUP到領域驅動設計(DDD)，舊的思維不斷的補強，成為更新、更完整的工具，例如：

1. DFD以 System Context Diagram 描述系統與外部系統的介接，藉以框住系統的範圍，DDD 轉化成 Bounded Context。
2. DFD Level 0的事件列表(Event List)，DDD將之強化為『事件溯源』(Event Sourcing)與『命令和查詢職責分離』(CQRS)。
3. 物件導向程式設計(OOP)興起，UML的類別圖(Class Diagram)變成顯學，DDD則進一步強化為領域模型，並引入聚合(Aggregate)/聚合根(Aggregate Root)/實體/值對象等概念。
4. 系統設計階段導入各種設計模式(Design Pattern)，包括Repository/Factory/Facade...等，配合各種現成的框架，如Java Spring、MS MVC、ORM等，期望一氣呵成的完成相關系統的開發。

圖五. System Context Diagram 與 Bounded Context 比較，圖形來源：微軟DDD文件指引、維基百科

領域驅動設計

講了那麼多，領域驅動設計的分析流程是甚麼呢? CQRS Journey畫了一張很有趣的圖，分為8個步驟，也附了一本書說明詳細作法。

不過，筆者比較喜歡另一本書『中台架構與實現：基於DDD和微服務』的思維，針對它建議的流程，稍作修改如下圖：

圖六. 領域驅動設計流程

在後續的文章，我們會針對每一步驟做詳細說明。

結語

看到那麼多的縮寫字、專門術語與圖形，讀者應該很頭痛，畢竟研究任一種方法論，都要花很多時間閱讀、理解進而實作，但是回報也是呈正比的，筆者就曾經靠『結構化分析與設計』方法論，獲得兩、三個工作機會，也靠這套方法論，完成數十個應用系統的開發，現在面對『領域驅動設計』的熱潮，也是值得再投入時間，將自己的檔次再提昇一級。

下一篇，我們會先依照系統分析方法論的演進過程，先介紹早期的『結構化分析與設計』(DFD)，說明其優缺點，再逐步比較領域驅動設計對應的作法。