Upgrade to Pro — share decks privately, control downloads, hide ads and more …

從領域知識到架構設計

James Wang
December 19, 2022

 從領域知識到架構設計

Domain-Driven Design Taiwan 於 2022/12/17 在台南府城分享主題。

# 講師
Sandy & James

# 主題簡介:
領域驅動設計 (DDD) 提供了一種基於領域知識的軟體設計方法,它可以幫助軟體開發人員更深入地理解商業領域,並創建更具表達力和靈活性的軟體架構。但是,如何設計是許多軟體開發人員面臨的挑戰。
將介紹 DDD 中軟體架構的核心概念和方法,包括如何捕捉領域知識、定義領域模型和分層架構等。我們可以更清楚地看到商業領域中不同部分之間的聯繫,並為軟體設計提供些許的指引。

# 活動連結:
DDDTW Tour - 府城站

James Wang

December 19, 2022
Tweet

More Decks by James Wang

Other Decks in Programming

Transcript

  1. 大家會遇到的問題 A big ball of mud is a haphazardly structured,

    sprawling, sloppy, duct-tape- and-baling-wire, spaghetti-code jungle. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. —Brian Foote and Joseph Yoder
  2. Domain Model B 你還需要 Domain User Interface Application Domain Domain

    Model A User Interface Application Domain Domain Model C User Interface Application Domain 領域分割 技 術 分 割
  3. 你還需要 Domain – BUT! Domain Model B User Interface Application

    Domain Domain Model A User Interface Application Domain Domain Model C User Interface Application Domain 1. 我們如何切分 Domain? 2. Domain 間如何 溝通? 3. 如何設計單 一 Domain? 1. 如何切分? 3. 如何設計? 2. 如何溝通?
  4. 利用 Event Storming 尋找邊界 • 可以透過進行 Big Picture 層級的 Event

    Storming,來探索領域邊界, 例如尋找業務流程中的關鍵事件(Pivotal Event)。 圖片來源:Introducing EventStorming (https://leanpub.com/introducing_eventstorming)
  5. Domain Storytelling • Domain Storytelling 用於幫助(開發)團隊學習 領域知識,近期開始受到 DDD 愛好者的推崇。 •

    Domain Storytelling 提倡將不同背景的人們拉在 一起,藉由敘述和視覺化領域故事彼此學習,設計 出符合能充分反映業務架構的系統。
  6. 利用 Domain Storytelling 尋找邊界 -以電影院為例 • 顧客向售票員購票的流程為票務子領域。 • 顧客向小販部購買餐飲的流程為餐飲子領域。 •

    顧客欣賞電影、播映人員播映電影的流程為播映子領域。 • 顧客入場、與驗票員互動的流程為驗票子領域。 • 整個業務流程可拆分為 票務、餐飲、播映、驗票 四大 子領域。 票務 餐飲 播映 驗票
  7. Domain Storytelling 劃分技巧 • 只有一個角色,獨自做了許多事 (Activities that only involve one

    actor) • 單向資訊流 (One-way information flow) • 不同的觸發點 (Different triggers) • 不屬於這個 domain story 的活動 (Activities supporting something that is not in the picture) • 同樣的事物有不同的名稱 (Difference in language) • 同樣的事物有不同用途 (Different use of the same thing) 劃分原則:從領域專家的角度,找到彼此歸屬在一起(belongs together)的活動。
  8. 以線上家教 平台為例 業務流程 1. 學生在平台填寫問卷 2. 平台將依問卷內容提供推薦老師清單給學生 3. 學生也可以自行瀏覽所有的老師清單 4.

    學生可以點選單一老師,查看該老師的詳細資料 5. 在購課前,學生可以與老師討論學習需求及目標 6. 學生在平台將課程包加入購物車 7. 學生於購物車頁面確認明細後,進行付款 8. 付款成功後,平台提供課程包給學生 9. 在購課後,學生可以與老師討論課程需求 10. 在購課後,學生向老師發起預約課程請求 11. 待老師確認預約請求後,才算預約成功 12. 課程的前10分鐘,平台向ZOOM取得課程連結 13. 平台提供課程連結給學生和老師 14. 學生及老師透過上課連結,進入ZOOM教室上課
  9. 從 Sub-domain 到 Bounded Context 我們透過 DDD 戰略設計 來探索並理解業務領域, 但我們的最終目標是要建立軟體,因此需要進一步設計解決方案。

    我們可以透過 DDD 分析業務領域,將複雜的領域劃分為數個子領域, 幫助我們來設計以 BC 為基礎解決方案。
  10. Domain, Sub-domain 及 Bounded Context • 一個組織所做的事情:要解決什麼問題、問題所處的環境、做事情的方法等等,例如企 業選定一個特定市場,提供產品或服務,如同我們常聽到的 domain know-how。

    Domain • 一個 Domain 可能非常的龐大且複雜,我們可以將它拆解為不同的子領域,例如在一個 家教領域中,可以拆分為老師目錄、課程下單、課程預約、課程進行等子領域。 Sub-domain • 在系統設計時,定義一組擁有明確邊界、職責清晰的領域模型,同一個 BC 內使用一致 的業務語言、定義、規則,並反映在我們所設計的領域模型中。 Bounded Context
  11. Context Map 定義:Context Maps describe the contact between bounded contexts

    and teams with a collection of patterns. 理想中,我們希望每個 Bounded Context 獨立自主提供業務服 務(無耦合)。 現實中,多個 Bounded Contexts 互相協作提供業務服務(低 耦合)。 所以接下來我們要識別出 Bounded Contexts 間的關連以及如 何溝通。
  12. Context Map - 識別上下游 U: Upstream 上游 D: Downstream 下游

    BC BC BC U U D D Downstream 依賴於 Upstream 外部系統 D U
  13. Integration Using Message Context A Context B Event Bus Outbox

    Outbox Inbox Inbox Event Handler Event Handler Source: GitHub - kgrzybek/modular-monolith-with-ddd: Full Modular Monolith application with Domain-Driven Design approach.
  14. Context Map 上加上溝通模式 BC BC BC U U D D

    外部系統 D U ACL ACL Queue 同步 非同步
  15. 依賴規則 Source code dependencies must point only inward, toward higher-level

    policies. 原始碼依賴關係只能指向內部,朝向更高層級的策略。
  16. 【高層】 【低層】 Dependencies Order Service Data Access Data Providers UI

    Web Api JSON JSON 依賴規則 – 舉個例子 User 我想查詢 訂單資料 Order Domain
  17. 【高層】 【低層】 Dependencies Order Service Data Access Data Providers UI

    Web Api JSON JSON 依賴規則 – 舉個例子 User 我想查詢 訂單資料 Order Domain <<Interface>> IOrderRepository 透過依賴反轉讓相依永遠從低層指向高層
  18. 關於高層不相依任何人 I have accepted Log4Net into the core because of

    its history of stability and small surface area. - Jeffrey Palermo 洋蔥架構提出者 Q:意思是最高層一定沒有相依任何第三方套件嗎? I have accepted Log4Net into the core because of its history of stability and small surface area. - Jeffrey Palermo 洋蔥架構提出者 Q:意思是最高層一定沒有相依任何第三方套件嗎?
  19. 猜猜我是誰? 猜猜我是誰 ├── catalog ├── inventory └── order ├── domain

    │ └── model │ └── order.ts ├── repository │ └── orderRepository.ts └── useCase ├── createOrder.ts ├── getOrderList.ts └── updateOrder.ts 猜猜我是誰 ├── api ├── application └── domain ├── aggregate │ └── order │ └── order.ts │ └── orderIdVO.ts │ └── catalog │ └── catalog.ts │ └── inventory └── service Source: 軟體架構淺談 - iT 邦幫忙
  20. 關於領域驅動設計 • 軟體開發的本質是滿足業務領域。 • 越複雜的領域,越需要被設計。 • 越複雜的領域越難設計,所以我們要將複雜的大問題拆分多個小問題。 • 小問題逐一解決,就沒有大問題了。 •

    所謂領域驅動設計,核心就在拆分,確立各種邊界(Boundary)。從 Domain 到 Sub-Domains 到 Bounded Contexts 到 Aggregates,一路 從戰略需求面到戰術實作面。 • 然而複雜領域無法一個人處理,所以要團隊大家與領域專家一起面對領域。