觀察的視角

我們要如何描述一個系統呢? 可以從不同的角度觀察，好比瞎子摸象，你摸到甚麼部位，系統就像那一個局部，那就慘了，因此，建議不要局限於方法論，應該從各種視角去觀察系統。

圖一. 系統觀察的視角(Viewpoints)

從上一篇知道 DFD 是從資料的流動與處理的角度觀察系統的功能，Yourdon隨後提出的個案是以事件為出發點描述系統，而領域驅動設計則是以事件加上實體(物件)角度出發，並且都加強了一些內容描述與整合，下面就來介紹相關的作法。

領域驅動設計以下簡稱DDD。

專案啟動(Kick-off)

事件風暴(Event Storming)是高階需求討論的一種手法，由 Alberto Brandolini 於2013年提出，它舉辦的方式類似IBM的Joint application design(JAD)、SCRUM的衝刺計劃會議(Sprint planning meeting)，是一種敏捷(Agile)的手法，想法是儘早讓使用者參與專案，以免像傳統的瀑布型開發方式，到了系統開發末期，一翻兩瞪眼，使用者說『這不是我要的』，就前功盡棄了。一般作法就是邀請重要的利害關係人，包括領域專家、使用者、專案開發成員一起討論願景與需求，通常是先發散(Diverge)再收斂(Converge)，先由所有人腦力激盪，天馬行空的提出各種想法，然後，再由主持人將想法合併歸類，事件風暴的作法是以事件為導向，整理出事件的觸發者、包含的實體及相關的訊息，包括參與的角色與權限等。

相關的手法可參考JAD、SCRUM，以下只列舉幾點說明：

1. 主持人至關重要，必須帶動氣氛，讓大家勇於發表意見，但又要及時踩剎車，將想法合併歸類，收斂後下結論，通常由業務經理或資深系統分析師擔任。
2. 會議室的佈置最好採圓桌或方形排列，象徵共同合作，切忌講台式或面對面兩列的排列，易造成一言堂或對立的氣氛，SCRUM則建議使用大牆壁，大家都站著，可隨意走動及小組討論。
3. 善用便利貼，可方便移動歸類。
4. 必須掌握時間，每次會議必須有結論，避免流於空談。
5. 透過會議可逐步建立共通語言(Ubiquitous Language)、手法及共識，開發團隊可整理出專門術語(Glossary)及其說明。

圖二. SCRUM 白板，圖片來源：dreamstim

產出

JAD訂定九項關鍵步驟(Key Steps)，可以參考，每個步驟應該有哪些產出，不過，DDD在此階段最重要的產出應該是：

1. 領域範圍(Bounded Context)：有人直翻為【限界上下文】，界定整體系統的範圍，並劃分各個子系統的界線，如下圖。
   
   圖三. 領域範圍(Bounded Context)，圖片來源：Using domain analysis to model microservices

2. 接著對每個領域範圍作進一步的分析，找出範圍內所有的事件，並清楚定義觸發者(Command)、Actor/User及處理流程，再從流程中提取實體(物件)，進而聚合(Aggegate)。

事件的觸發者有很多種：

• 交易：例如銷售、投保、存提款。
• 排程：每日固定時間執行。
• 資料變動：例如庫存低於安全存量、儲水量高於滿水位、工作流程系統傳來一筆資料、物聯網接收到感測器資料、系統異常訊息...等。

維基百科有非常棒的定義，最後整理成圖四，複雜一點可能變成圖五，圍繞整個辦公室。

圖四. 事件風暴的產出，圖片來源：Model Event Storming Results in Context Mapper

圖五. 事件風暴的產出奇觀，圖片來源：Make Collaboration Better with Event Storming

最後將事件風暴的產出整理成表格，或像DFD的Context Diagram，就是一份很完整的高階系統規劃書。

3. 聚合(Aggegate)：是將相關的實體(物件)歸類在一起，並找到聚合根(Aggegate Root)，亦即主要的實體，它像肉粽串的頭，可以藉著它一把抓起所有的實體，類似主資料表，藉由Foreign Key關聯其他資料表，例如商品主表，關聯產品類別表、各倉庫存量表、供應商表...等。
   
   圖六. 聚合(Aggegate)

圖七. 領域範圍(Bounded Context) + 實體(Entity)，圖片來源：How the Domain-Driven-Design is the ideal architecture to develop IoT Services?

結語

透過以上的活動，我們就可以得到一個系統的全貌，接下來由上向下(Top Down)展開，逐步細緻化，就可以完成整個系統的設計與開發。