團隊協作實戰DDD
•Télécharger en tant que PPTX, PDF•
6 j'aime•1,441 vues
從要達成的業務目標為起點，開發團隊如何與領域專家一起合作，找出可能有價值的關鍵需求，基於這些關鍵需求發展通用語言與建立領域模型，並且從戰略層面決定架構策略，從戰術層面實作系統細節。
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à 團隊協作實戰DDD
Similaire à 團隊協作實戰DDD (20)
團隊協作實戰DDD
- 2. HELLO! I am Jed Growth Machine Senior Architect CSM, CSPO, CSD 2
- 3. AGENDA ⊡ 軟體開發要解決的問題 ⊡ 共識是基礎 ⊡ 基於共識的建模方式 ⊡ 問題拆分與解決方案 ⊡ 聚合建模與實作 ⊡ Context Mapping 3
- 5. 軟體開發要面對的問題 ⊡ 業務問題 □ 推廣網站，吸引陌生訪客 □ 讓訪客願意註冊成為會員 □ 讓瀏覽商品頁的訪客完成 一筆購物交易 ⊡ 技術問題 □ 商品頁面的分頁查詢 □ 商品的關鍵字查詢 □ 與銀行介接線上支付 5
- 7. 軟體開發要面對的問題 ⊡ 關注點分離 □ Subdomain and Bounded Context ⊡ 用同樣的語言對話 □ Ubiquitous Language 7
- 9. “ System architecture should reflect the end users’ mental model of their world. 9
- 10. 如何建模 – 從說故事開始 ⊡ 阿光3C小舖 □ 阿光是一個在FB販售3C商品的小賣家，由於他的服務 很好，部份主力商品又能拿到較低的進貨價，跟他購買 3C商品的顧客漸漸變多。 □ 新的一年他為自己定下了營業目標，希望與去年同期相 比，單月有效下單數成長50%。 □ 在他努力之下，客戶數與訂單增長，但他也發現原本採 用人工收單與對帳的交易方式太沒有效率，限制了業績 成長 11
- 11. 如何建模 – 從說故事開始 ⊡ 制定戰略目標，開發與業務目標一致 12 As I want (to) So that
- 13. 如何建模 – 從說故事開始 14
- 15. “ It’s not a bug, it’s an undocumented feature. 16
- 16. 建立共識 眼前的黑不是黑，你說的白是什麼白 ⊡ Ubiquitous Language – 發展通用語言 □ 不要局限於名詞 □ 不是將需求文件化 □ 能夠描述子領域的具體場景 □ 建立所有人對需求的共識 17 https://www.infoq.com/articles/ddd-contextmapping
- 18. 建立共識 眼前的黑不是黑，你說的白是什麼白 ⊡ 實例化需求 (Specification by Example) □ Cucumber的Gherkin語法 ■ 英文：GIVEN – WHEN – THEN ■ 中文：假設 – 當 – 那麼 ⊡ 行為驅動開發(BDD) ⊡ 測試驅動開發(TDD) 19
- 20. 實例化需求工作坊 SHARE UNDERSTANDING ⊡ 需求： □ 會員登入 21
- 21. 建立共識 眼前的黑不是黑，你說的白是什麼白 ⊡ 小明在阿光3C小舖購買一台13吋的Mac Book Pro 22 假設 小明下單購買13吋 Mac Book Pro 且 單價為<43900> 數量 1 台 當 完成輸入資料: <姓名> <住址> <聯絡電話> 且 選擇任一付款方式 那麼 訂單單號<ae014733-6ee3-4d09-898b- 3024594fff68>成立 假設 訂單單號<ae014733-6ee3-4d09-898b- 3024594fff68>金額為<43900> 當 小明選擇<信用卡付款> 那麼 系統為該筆訂單產生一筆應付金額為 <43900> 且 已付金額為<0> 且 狀態為<未付款>的付款記錄 假設 訂單單號<ae014733-6ee3-4d09-898b- 3024594fff68>的付款記錄，應付金額為 <43900> 且 付款記錄狀態為<未付款> 當 收到銀行端回傳刷卡成功代碼<01> 且 刷卡金額為<43900> 那麼 變更該筆訂單的已付金額為<43900> 且 付款記錄狀態為<已付款>
- 25. ⊡ 問題拆解 假設 小明下單購買13吋 Mac Book Pro 且 單價為<43900> 數量 1 台 當 完成輸入資料: <姓名> <住址> <聯絡電話> 且 選擇任一付款方式 那麼 訂單單號<ae014733-6ee3-4d09-898b- 3024594fff68>成立 假設 訂單單號<ae014733-6ee3-4d09-898b- 3024594fff68>金額為<43900> 當 小明選擇<信用卡付款> 那麼 系統為該筆訂單產生一筆應付金額為 <43900> 且 已付金額為<0> 且 狀態為<未付款>的付款記錄 假設 訂單單號<ae014733-6ee3-4d09-898b- 3024594fff68>的付款記錄，應付金額為 <43900> 且 付款記錄狀態為<未付款> 當 收到銀行端回傳刷卡成功代碼<01> 且 刷卡金額為<43900> 那麼 變更該筆訂單的已付金額為<43900> 且 付款記錄狀態為<已付款> 問題拆解 Subdomain 與 Bounded Context 26
- 26. 問題拆分與解決方案 Subdomain 與 Bounded Context 27 訂單 收貨人資料 商品品項 付款記錄 付款方式 線上支付交易 記錄 訂單子領域 付款子領域
- 27. 問題拆分與解決方案 Subdomain 與 Bounded Context 28 訂單 收貨人資料 商品品項 付款記錄 付款方式 線上支付交易 記錄 Order Bounded Context
- 28. 問題拆分與解決方案 Subdomain 與 Bounded Context ⊡ Bounded Context裡面有什麼? □ Domain □ Service □ API □ DB □ UI □ … 29 Clean Architecture – Uncle. Bob
- 29. 聚合建模與實作 5 30
- 30. 聚合建模與實作 藉由領域事件找到聚合模型 ⊡ 聚合(Aggregate) □ 其實是一種pattern，Transaction的邊界 ⊡ 實體(Entity) □ 不是DB裡的Table，也不是某個ORM Framework ⊡ 值物件(Value Object)跟DTO (Data Transfer Object)的關係 □ 沒有關係 31
- 32. 聚合建模與實作 藉由領域事件找到聚合模型 ⊡ 領域事件 (Domain Event) 又是什麼? 33
- 33. 聚合建模與實作 藉由領域事件找到聚合模型 ⊡ 訂單新增成功是一個領域事件 □ 建立一筆新訂單需要知道? ■ 買了什麼? ■ 訂單金額? ■ 收貨人資料? □ 付款關心的是? ■ 訂單單號 ■ 應付金額 34 假設 小明下單購買13吋 Mac Book Pro 且 單價為<43900> 數量 1 台 當 輸入收貨人資料: <姓名> <住址> <聯絡電話 > 且 選擇任一付款方式 那麼 訂單單號<ae014733-6ee3-4d09-898b- 3024594fff68>成立 假設 訂單單號<ae014733-6ee3-4d09-898b- 3024594fff68>金額為<43900> 當 小明選擇<信用卡付款> 那麼 系統為該筆訂單產生一筆應付金額為 <43900> 且 狀態為<未付款>的付款記錄
- 34. 聚合建模與實作 藉由領域事件找到聚合模型 35 ⊡ 訂單的領域事件： □ OrderCreated □ OrderItemAdded □ ShippingInfoUpdated 假設 小明下單購買13吋 Mac Book Pro 且 單價為<43900> 數量 1 台 當 完成輸入資料: <姓名> <住址> <聯絡電話> 且 選擇任一付款方式 那麼 訂單單號<ae014733-6ee3-4d09-898b- 3024594fff68>成立
- 36. 聚合建模與實作 藉由領域事件找到聚合模型 37 訂單 收貨人資料 商品品項 付款記錄 付款方式 線上支付交易 記錄 Order Bounded Context OrderCreated Payment Bounded Context
- 40. “ organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations. 44
- 41. 問題拆分與解決方案 Subdomain 與 Bounded Context 45 訂單 收貨人資料 商品品項 付款記錄 付款方式 線上支付交易 記錄 Order Bounded Context Payment Bounded Context Payment Integration Bounded Context
- 42. Context Mapping 綜覽全局的戰略設計 46 訂單 收貨人資料 商品品項 付款記錄 付款方式 線上支付交易 記錄 Order Bounded Context Payment Bounded Context Payment Integration Bounded Context 依賴關係
- 43. Context Mapping 綜覽全局的戰略設計 ⊡ 管理團隊與架構之間的關係 ⊡ 明確的依賴方向 ⊡ 制定持續整合的關鍵 ⊡ TOC限制理論中的瓶頸 47
- 44. Context Mapping 綜覽全局的戰略設計 ⊡ 整合與管理 □ Partnership □ Shared Kernel □ Consumer-Supplier □ Conformist □ ACL □ Open Host Service □ Published Language □ Separate Ways □ Big Ball of Mud 48
- 45. Context Mapping 綜覽全局的戰略設計 ⊡ 放眼未來，當業務成長後… □ 領域愈來愈複雜 □ 組織變動 □ 專案規模變大，時間變長 □ 外部或遺留系統 □ 團隊 ■ 人數成長 ■ 多個開發團隊 ■ 遠端團隊 49
- 47. Context Mapping 綜覽全局的戰略設計 51 團隊 領域專家 使用者 業務目標、 問題、需求 Bounded Context Bounded Context Bounded Context Ubiquitous Language Domain Model Production Code Test Code 發展 重構 拆分 分析與建模 提煉 指導 管理 對話 驗證
Notes de l'éditeur
- 目前的職務是資深架構師 主要專注在高流量的線上交易系統架構設計與開發 熟悉軟體開發相關工程實踐，如TDD/單元測試/重構等等 從2010年接觸到DDD後，就開始嘗試在實務上學習與實踐DDD 在踩過不少坑後，也獲得一些體悟
- 做業務的有時是一個idea出來，需要實作出來，去嘗試看看市場反應 而做技術的實現這個idea時，需要理解這個idea的方方面面，實現出來的才是正確的 當2大塊揉合在一起時，這個問題就會變的很複雜
- 規模太大，想解決的問題太多 雖然都是想把事情做好，但看事情的角度不同，面對的問題也會不同，解決方式自然也不一樣 領域專家與開發團隊沒有共同的語言，難以取得共識 怎麼辦?
- 我覺得DDD的作者在書裡沒有講的很清楚的部份有好幾個 其中一個就是怎麼建模
- 系統架構應該反映出end user的心智模型
- 100個專家，100個答案 抽象
- Goal -> Actor -> Impact -> Deliverable 為什麼要有Impact Mapping? 因為常會把要交付的功能當成我們工作的目標 這些叫output，不是outcome 透過Impact Mapping，分離出不同角色的故事，在目標導向的前提下，證明這些是有價值的 目標要能被衡量 找出可能有價值，決定要開始實驗的故事之後?
- 為什麼要有User Story Mapping ? User Story Mapping可以幫助團隊重新組織需求，從時間關聯可以組織好一系列的故事，從優先順序可以找出要交付的功能價值高低
- 藉由User Story Mapping，我們可以結構化的組織需求故事，找到一系列最優先要交付的功能，這可能包含了我們要關注的核心子領域
- 對開發團隊來說，這樣的故事還不足以開發，有很多細節要討論 接下來我們透過這個案例，看看實例化需求要如何幫助我們理解
- 20分
- 藉由實例化的討論，團隊可以比較容易的獲得關鍵需求的細節 對PO/BA的角色來說，可以少一點文件，多一點對話
- 最簡單的方式就是從一些名詞與動詞找出具代表性的領域概念，而這些概念將會是接下來發展通用語言的重點
- 拆成2個不同的子領域，要解決的問題是不同的 子領域內真正要解決的問題，要視通用語言描述的具體場景而定 訂單子領域： 新增/取消訂單、新增/變更收貨人資料、新增/變更商品品項… 付款子領域： 新增付款記錄、變更付款狀態、線上支付整合…
- 假設訂單領域是核心領域，而我們現在要開發能解決訂單領域內各種問題的系統，先不看其他部份，那麼這個Order Bounded Context裡面應該要有什麼?
- 而整個Bounded Context從概念上來看，包含了一整組能實現業務活動的各類元件 從程式碼命名上，則是有語義的，能直觀的理解在領域裡的各種行為 在通用語言上，則是沒有歧義的 (有點抽象)
- 個人對找Aggregate的定義是： 要找到一組能緊密合作的領域物件，負責處理領域中特定的Transaction行為，維護資料的一致性原則 AggregateRoot：指在這一群領域物件裡，找到一個負責人，有事就是找它就對了 為了快速的找到這個頭目，你就要給他一個編號，比如9527 所以AggregateRoot必然是Entity，但Entity不一定是AggregateRoot
- 當我們看到一個事件發生了，就可以從這個事件發生後的相關訊息，去推斷這個事件是怎麼發生的 所以我們透過已發生的領域事件，就可以去推斷我們的領域模型要具備哪些條件，才會再次引發這個領域事件 且由於事件與事件之間存在著因果關係，可以表達出交易的一致性模型
- 面對複雜問題的基本功就是關注點分離 拆解、分類、排序 以Event Driven的方式來設計架構 不變性(Immutable)
- Conway’s law 每個系統都有一個架構 架構由架構元素以及相互之間的關係構成 系統是為了滿足利益相關者（stakeholder）的需求而構建的 利益相關者都有自己的關注點（concerns） 架構描述了一系列的架構視角 每個視角都解決並且對應到利益相關者的關注點。
- 如果說Subdomain是業務面對的挑戰，那Bounded Context則是解決方案 DDD常聽到的『運用Context Mapping進行戰略設計』，這句話是什麼意思? 說白話就是要會兌子，為了達到戰略目標，犧牲掉無關大局的部份，可以是人，可以是流程，可以是你覺得很有彈性的戰術設計
- Bounded Context是強調邊界的，而這些Bounded Context同時也代表著技術解決方案，當我們看到這些解決方案之間的依賴關係，就要有意識這是架構設計要解決的問題
- Context Map是從戰略的角度來管理架構與團隊之間的關係 每個Bounded Context會交由一個Team來負責開發，而一個Team會負責一到多個Bounded Context 不同的Bounded Context之間如何協調合作，就是看Bounded Context的上下游關係。 這直觀的反映出團隊與架構之間的關係，也自然地符合康威定律 步驟一、找出系統的瓶頸。 步驟二、決定如何利用瓶頸。 步驟三、根據上述的決定，調整其他的一切。 步驟四、把系統的的瓶頸鬆綁。(就是解決它) 步驟五、假如步驟四打破了系統原有的瓶頸，那麼就回到步驟一 什麼需要改變？（What to change?）：首要之務就是找到阻礙其達到更高的績效的限制或核心問題。然後把他弄清楚了。 改變成什麼？（What to change to?）：針對上述之核心問題，尋找解決方案，希望能夠真正達到消除阻礙，讓系統達到高績效。 如何產生變動？（How to cause the change?）：當找到解決方案後則必需進一步分析其障礙為何，並轉換成實施步驟讓大家都弄清楚了，以期順利推行變動。
- Partnership: 同生共死 Shared Kernel: 共享核心程式碼 Consumer-Supplier: 上下游，彼此積極友好合作 Conformist: 上下游，但下游只能吃上游給的東西
- 核心領域並非一成不變，會隨著企業的經營方向產生新的核心領域
- 從要達成的業務目標為起點，開發團隊如何與領域專家一起合作，找出可能有價值的關鍵需求，基於這些關鍵需求發展通用語言與建立領域模型。 並且從戰略層面決定架構演進策略，從戰術層面實作系統細節。