Download to read offline
Uploaded byteddysoft
Dci vs aggregate_dddtw_2021-0.3-preview
本文讨论了领域驱动设计（DDD）和清洁架构的关键概念，包括上下文、角色和使用案例的动态互动。强调了商业逻辑的分类及其在架构中的重要性，并提出了在特定上下文中理解算法的必要性。文章还通过实例展示了如何在团队设计中实现角色扮演和动态行为。
![[演講] Scrum導入經驗分享](https://cdn.slidesharecdn.com/ss_thumbnails/scrumintro-2014-05-27-web-140527194705-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
![[教材] 例外處理設計與重構實作班201309](https://cdn.slidesharecdn.com/ss_thumbnails/201309-130917200320-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
Dci vs aggregate_dddtw_2021-0.3-preview
- 1. Teddy Chen teddy@teddysoft.tw http://teddy-chen-tw.blogspot.tw/ Oct. 162021 @ DDD TW 16:30~17:20
- 2.
- 3. • 聽過DDD請舉手 • 實作過DDD請舉手 •聽過DCI請舉手 • 實作過DCI請舉手 • 以上皆是請舉手 Copyright@2021 Teddysoft
- 4.
- 5. • 土豆 • 勉強 Copyright@2021Teddysoft
- 6. 1. 事 物的 意 義 , 須 放 在 特 定 Context 之下討論才有意義 2. 相 同 概 念 ( 名 詞 ), 在 不 同 Context之下可能有不同意義 Copyright@2021 Teddysoft
- 7. Copyright© 2021 Teddysoft《ezKanban》
- 8.
- 9. Copyright© 2021 Teddysoft《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.
- 11.
- 12.
- 13.
- 14.
- 15. Copyright© 2021 Teddysoft《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
- 16. Copyright© 2021 Teddysoft《Clean Architecture》
- 17. • 商業邏輯要放在哪裡? EntityLayer 或 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 • 如何重複使用商業邏輯? Copyright@2021 Teddysoft
- 18. Copyright© 2021 Teddysoft《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.
- 20.
- 21.
- 22. • Data – 資料類別，原本充血模型類別的演算法被抽離出來放到角色（Role） –Role是沒有狀態的類別，類似domain service。但在DCI架構中， Data可以在執行期間動態扮演不同角色 – Data扮演某個Role之後，該Data物件看起來就變成屬於該Role的型別， 可以執行該Role所定義的方法 • Context – 物件的演算法必須放在一個特定情境（Context）去討論才可知道它 的意義，這個情境就是使用案例 • Interaction – 使用案例藉由指派若干Data物件扮演不同Role，並控制物件之間的協 作來完成使用案例，稱為互動（Interaction） Copyright@2021 Teddysoft 《The DCI Architecture by Trygve Reenskaug and James O. Coplien》
- 23.
- 24.
- 25.
- 26.
- 27. • Step 1:定義 TeamRoles => Content, Membership, BoardAccess 與每一個角色需要使用的Data class • Step 2: 實作 MembershipRole, BoardAccessRole • Step 3: 重構 Team – 實作TeamRoles.Content, MembershipRole, BoardAccessRole – 使用 TeamRoles.TeamData – 使用 MembershipRole, BoardAccessRole • Step 4: 重構 Team使其支援角色扮演 – 讓Team繼承DciAggregateRoot – 修改 use case 測試案例，使用 playRole 來執行程式 • Step 5: 新增角色BoardContentRole並將其動態加入Team Copyright@2021 Teddysoft 請看IntelliJ
- 28.
- 29.
- 30.
- 31.
- 32. • 有感的好處 – 簡化Aggregate設計、實作與測試 •真，單一責任 – 依據角色重新排版Event Storming • 有疑惑的理論好處 – 已經透過Event Storming切割出Task-Based使用 案例(Command)，在此情況下是否真的需要DCI 強調的動態扮演不同角色的彈性? – Task-Based使用案例沒有很複雜的Interaction Copyright@2021 Teddysoft
- 33.
- 34.
- 35. • 搞笑談軟工部落格 – http://teddy-chen-tw.blogspot.com •搞笑談軟工Facebook – https://www.facebook.com/groups/teddy.tw • 泰迪軟體官方網站 – http://teddysoft.tw Copyright@ 2021 Teddysoft