Applying DCI in DDD

1. Teddy Chen
teddy@teddysoft.tw
http://teddy-chen-tw.blogspot.tw/
Oct. 16 2021 @ DDD TW

3. • 聽過DDD請舉手
• 實作過DDD請舉手
• 聽過DCI請舉手
• 實作過DCI請舉手
• 以上皆是請舉手

5. • 土豆
• 勉強
• OK

6. 1. 事 物 的 意 義 , 須 放 在 特 定
Context 之下討論才有意義
2. 相 同 概 念 ( 名 詞 ), 在 不 同
Context之下可能有不同意義

7. 《ezKanban》

8. Bounded Context裡面有什麼?

9. 《Domain-Driven Design: Tackling Complexity in the Heart of Software》
Domain
Events
Ubiquitous
Language
Bounded
Context define model within
names enter
model gives structure to
express model with

10. 《ezKanban》

11. 貧血好還是充血好?

12. 傳統物件導向觀點認為
充血模型比貧血模型好

13. DDD的領域模型是
貧血還是充血模型?

14. • Context決定意義
• 常見的DDD Context有:
–Bounded Context
–Domain Model裡面的類別→相當於Clean
Architecture的Entities Layer
• DDD的Domain Model通常屬於充血模型

16. Use Case是一種Context嗎?

17. DDD有提到Use Case嗎?

18. 《Domain-Driven Design: Tackling Complexity in the Heart of Software》
Domain
Events
Ubiquitous
Language
Bounded
Context define model within
names enter
model gives structure to
express model with

19. 《Clean Architecture》

20. • 商業邏輯要放在哪裡? Entity Layer 或 Use Case Layer
(Application Service Layer) ?
• Clean Architecture 說
– Entity Layer
• Critical Business Rules
– Use Case Layer
• Application-Specific Business Rules
• 怎麼區分商業邏輯是Critical或Application-Specific?
– It….depends! Orz
• 如何重複使用商業邏輯?

21. 《Domain-Driven Design: Tackling Complexity in the Heart of Software》
Domain
Events
Ubiquitous
Language
Bounded
Context define model within
names enter
model gives structure to
express model with

23. 請看瀏覽器

24. • 在DDD中，Bounded Context內的系統行為(商業邏
輯) 分散在不同階層的不同物件身上
• Aggregate Root的public method相當於一個小型的
使用案例 (task-based use case)
• 因此, Aggregate Root相當於一組task-based use
cases的集合, 可能導致:
–程式碼太多?
–違反單一責任原則?

26. • Data
– 資料類別，原本充血模型類別的演算法被抽離出來放到角色（Role） 。
– Role是沒有狀態的類別，類似domain service。但在DCI架構中，Data可以在執行期間動
態扮演不同角色。
– Data扮演某個Role之後，該Data物件看起來就變成屬於該Role的型別，可以執行該Role所
定義的方法。
• Context
– 物件的演算法必須放在一個特定情境（Context）去討論才可知道它的意義，這個情境就是
使用案例。
• Interaction
– 使用案例藉由指派若干Data物件扮演不同Role，並控制物件之間的協作來完成使用案例，
稱為互動（Interaction）。
《The DCI Architecture by Trygve Reenskaug and James O. Coplien》

27. DCI為什麼主張在使用案例中動
態決定程式行為的意義? 為什麼
不是把程式行為綁定在類別身上,
由類別決定?

28. 程式範例 (下頁)

30. 請看IntelliJ

31. • Step 1: 定義 TeamRoles
– Content, Membership, BoardAccess 與其所使用的Data class
• Step 2: 實作 MembershipRole, BoardAccessRole
• Step 3: 重構 Team
– 實作 TeamRoles.Content, MembershipRole, BoardAccessRole 介面
– 使用 TeamRoles.TeamData
– 使用 MembershipRole, BoardAccessRole instances
• Step 4: 重構 Team 支援角色扮演
– 讓Team繼承DciAggregateRoot
– 修改 use case 測試案例，使用 playRole 來執行程式
• Step 5: 新增角色BoardContentRole並將其動態加入Team
請看IntelliJ

32. • 充血模型是富人的貧血模型
• 貧血模型是富人的充血模型
< http://teddy-chen-tw.blogspot.com/2021/09/22.html >

34. • 有感的好處
– 簡化Aggregate設計、實作與測試
• 真，單一責任
– 依據角色重新排版Event Storming
• 有疑惑的理論好處
– 已經透過Event Storming切割出Task-Based使用案例
(Command)，在此情況下是否真的需要DCI強調的動態扮
演不同角色的彈性?
– 透過Domain Event達到跨Aggregate的狀態最終一致性，
因此Task-Based使用案裡面並沒有很複雜的Interaction

35. • 後續探討議題
–DCI動態指派角色的特性是否與Aggregate Root定義衝突?
• Business operations, stage machines, transaction
boundaries, aggregate invariants, return immutable entities
to its callers
• Event sourcing
–不同程式語言實作方法與效能問題
–Business Rules 放在Entities Layer or Use Case Layers?
(下一頁)

37. • Context決定意義
• DDD中的「靜態」Contexts
– Bounded Context
– Domain Model: Entity, Value Object, Aggregate, Service
• DCI藉由在Context (使用案例) 中動態指派角色給資料類別
達到提升程式可讀性與重複使用性的目的

38. • 程式範例
– https://gitlab.com/TeddyChen/dci-demo
• 搞笑談軟工Facebook
– https://www.facebook.com/groups/teddy.tw
• 搞笑談軟工部落格
– http://teddy-chen-tw.blogspot.com
• 泰迪軟體官方網站
– http://teddysoft.tw