AgileTour Hsinchu 2018 - 工作坊

1. 領域驅動設計
工作坊
1

3. 一個開發該有的姿勢

4. 真實世界總是…
參考鏈結

5. 參考鏈結
專案成功率

6. 為什麼我們執行一個專案/產品這麼困難?
6

7. 聽過這座塔的故事嗎?
7

8. 溝通的失敗,讓偉大的工程無以為繼

9. 溝通力 = 執行力

10. 領域驅動是什麼?
10
戰略
戰術
戰技
促進溝通並探索問題領域
設計解決方案
基本能力

12. 需求分析
參考鏈結

13. 辛苦的成果,有時候連自己也看不懂

14. 參考資料
利用其它UML圖協助

15. 最後…團隊多了好幾本文件要讀

16. 準備超長的壁報紙 事件探索 聚合 + Context Map Modeling
Design
16

17. 1 2 3
事件和動作有什麼不同呢？
行為 事件
17

18. 買早餐
已經買早餐
有什麼區別?
18

19. Past
• 採用過去式描述
• 事件彼此之間不相依
• 範例:
已購票(Ticket Bought)
19

20. 事件
事件的發生是有強列的順序性
事件
20

21. 事件意味著證據
21

22. 事件1 事件2 事件3
由左至右
呈現事件發生順序
22
* 事件探索的建議:
1. 盡可能細化,找出更多事件
2. 不要過早抽象化
3. 不要過早考慮例外處理,先以快樂路徑(Happy path)為主

23. 事件1 事件2 事件3
事件2’
平行事件的處理方式
23

24. 事件1 事件2 事件3
事件2’
添加命令
命令
24

25. 事件1 事件2 事件3
事件2’
命令的發起者是誰?
命令
角色
25

26. 事件 事件
事件事件
事件 事件 事件
事件
豐富你的事件
命令
角色
26
事件

27. 或許是由User所執行的
命令而來
或許是由外部系統
所觸發
或許只是表達某個特定
間需要做的事
或許它是銜接另一個事件
事件從何而來?

28. Refund
Request
Received
Refund
Policy
Issue
Refund
Refund
Issued
Notificaton
Sent to
Payee
外部系統所引發的事件
商務流程中,極
有可能會使用
到外部系統

29. 決策流程
人為
促進人為決策
的輸入(Input)
Refund
Request
Received
Refund
Policy
Issue
Refund
Refund
Issued
Notificaton
Sent to
Payee
Organizer
流程有可能是需要人為介入

30. 事件4事件1 事件2 事件3
事件2’
找出機會/風險
命令
角色
30

31. 排序你的機會/風險
This is
where
everything
is stock!
This is
where
everything
is stock!
This is
where
everything
is stock!
This is
where
everything
is stock!
This is
where
everything
is stock!
31
淘汰

32. 要先找出問題,才能設計
解決方案,如果顛倒了順
序,就會事倍功半。
32
問題領域 和 解決方案領域

33. 先瞄準再射擊
33

34. 切割成多個問題子領域
核心子領域
(Core Subdomain)
支持子領域
(Supporting Subdomain)
支持子領域
(Supporting Subdomain)
通用子領域
(General Subdomain)
問題域(Problem Domain)
依照價值(Value)將一個
問題領域切割成為多個
子問題領域。
核心子領域是最有價值的。
34

35. 通用子領域
: 採用現成服務
支持子領域
: 採用外包
核心子領域
: 傾團隊之力
35

36. This is
where
everything
is stock!
This is
where
everything
is stock!
This is
where
everything
is stock!
This is
where
everything
is stock!
This is
where
everything
is stock!
將排序最高的風險/機會
列為核心子領域。
團隊最好能夠得到管理者
的承諾與支持。
挑選核心子領域

37. 怎麼確定那個風險/機會是最重要的?
價值是從最重要的利害關係人角度出發

38. 除了風險/機會之外,
還有什麼角度?

39. 財務貢獻
戰略效應
(Financial Impact)
(Strategic Impact)
戰略支持
能力
核心
競爭力
商務
基底
商務
支撐力
高
高低
低
依照商業能力進行分析
參考資料

40. 由不同觀點看待
機會/痛點
(Rick / Pain Point) 商務能力
(Business Capability)

41. 設計解決方案
每個問題子領域,都應該會
有解決方案,而這些解決
方案,在DDD中,稱其為:
限界上下文。
限界上下文
限界上下文
限界上下文
限界上下文
限界上下文

42. 在事件風暴中,先找出
聚合,再找出限界上下文。
這就是先求內聚,再看耦合
探索聚合(Aggregate)
把相同功能目標的事件收攏在一起

43. 聚合
事件
事件
事件
事件
命令
角色
事件
事件
事件
事件
命令
角色
43
命令
命令
命令
命令
每一個聚合都是為了相同
的功能目的。
命令與事件都是參考元素。

44. 在事件風暴中,先找出
聚合,再找出限界上下文。
這就是先求內聚,再看耦合
探索限界上下文
把相同功能目標的聚合收攏在一起

45. 限界上下文
(Bounded Context)
事件
事件
事件
事件
命令
事件
事件
事件
事件
命令
產品
事件
事件
事件
事件
命令
事件
事件
事件
事件
命令
將相同功能目的的
聚合放在一起,進而
形成一個限界上下文。
45

46. 限界上下文之間其實並非
完全獨立,它們還是會存在
關聯性(Association)。
探索限界上下文圖

47. 限界上下文圖
(Context Map)
47
U
U
U
D
D
D
上游的改變會嚴重影響
到下游,藉這張圖瞭解
系統變更所可能引發的
風險。

48. 限界上下文圖模式
(Context Map Pattern)
模式大概有9種,但是可以
粗略地分成兩種：
• 協作
• 整合
參考資料

49. 參考資料
一個完整的範例

50. 團隊溝通
重工
系統整合
團隊協作
資源分配
沒有上下文圖之前的窘境…
上下文圖提供更高的商務
視野,讓高階管理人員能夠
更快的理解資源分配和
組織概況。

51. 上下文圖與團隊組織
上下文圖也暗示了許多
與團隊組織相關的訊息。

52. 52

53. 重新看待聚合
業務上的聚合,需要進一步設計

54. 聚合畫布
(Aggregate Canvas)
名稱
輸入 模型 輸出
• 命令(Command)
• 驅動模型運作
• 以統一語言進行建模
• 可以使用Stereoype去標示:
• Entity
• Value Object
• Domain Service
• 領域事件(Event)
• 先不著急命名

55. Order
Create
Order
Update
Order
Cancel
Order
Order
Created
Order
Updated
Order
Canceled
<<Entity>>
<<VO>>
<<Entity>>
<<Entity>>
<<VO>>
<<Entity>>
範例-聚合畫布
(Aggregate Canvas)

56. 交易樣式
(Transaction Pattern)
參考鏈結

57. 四色建模
(Four Color Modeling)
參考鏈結

58. 建模到底在做什麼?
對統一語言進行圖型化描述

60. DDD戰技概觀

61. • 一個聚合是一個完整的交易(Transaction)概念
• 當交易所異動到的資料表過於龐大,會造成效能議題(Issue)
• 適當拆解聚合(i.e. 不違反BASE理論為前題)
• 考慮採用文件型資料庫(NoSQL)
聚合設計原則

62. CAP理論
參考鏈結

63. 參考鏈結
三者之間的關係
DDD從BDD和TDD上借力,
讓設計更加地完整。

64. BDD/TDD測試案例的切入點
BDD
TDD
從命令著手,進行
系統行為分析
將模型以TDD
進一步驗證

65. CAE三者的互動模式
(Command, Aggregate, Event)
參考鏈結
Aggregate接收Command,
並在處理完畢後拋出Event
若有需要流程控制,會再加
上Process Manager這個
Domain Service。

66. 參考鏈結
參考鏈結
六角架構
DDD的模型在最內部的
核心,而越是往外,則代表的
易變性與脆弱。
六角的外部是Port/Adapter,
它們是模型與外部溝通
的工具

67. 參考鏈結
組成微服務架構
以六角堆疊出宛若蜂巢的微服務

68. 服務在微服務中的真面目
參考鏈結
微服務不在於服務的代碼
有多小,而在於其本身的
商務能力有多麼 -
明確與凝煉。

69. 響應式系統設計
參考鏈結
事件驅動的架構模式讓
系統變得更有彈性和
擴充性,是個可以考慮的
架構模式。

70. Aggregate A
Aggregate B
Aggregate C
Bounded Context A
Bounded Context B
• 領域事件是用於同一個限界上下文
中Aggregate之間相互溝通
• 整合事件(Integration Event)是為了”交易(Transaction)”;
目標在於達成最終一致性(Eventually Consistency)
整合事件 領域事件
領域事件
領域事件
整合事件

71. 命令
事件
聚合
事件
策略
Given
When Then
外部系統
UI/UX
Alternatives啟動BDD
Personas
以User為中心
的系統
警報
基於系統真實
事件的BI
打造自動化的
系統
Matrix
參考資料

72. PO
我從限界上下文
地圖了解系統概
觀,並且讓我可以
依市場快速調整
資源!
Contributors
Designer:
我了解資料流
的來龍去脈
Developer:
模型都有了,我
只要按圖施工
QA:
驗收條件的分
析,清晰明朗!
Scrum Master
團隊成員能夠快速
吸收領域知識,真的
是節省了我好多
時間和心思!
Gain

74. Recap
DDD具有兩個環節
戰略, 戰術
利用事件風暴完成
知識獲得, 上下文圖
聚合設計原則
輕巧, 符合BASE理論
事件
整合事件, 領域事件