When agile meets domain-driven design (ddd)
•Download as PPTX, PDF•
0 likes•453 views
Agile Summit 2021 Speech
Recommended
Recommended
More Related Content
Recently uploaded
Recently uploaded (20)
Featured
Featured (20)
When agile meets domain-driven design (ddd)
- 2. Myname’s Michael 樂屋國際資訊 產品處 副總經理 台灣敏捷協會 理事 DDD TW Community 組織者 HELLO!
- 3. BeingAgile between efficiencyand effectiveness ● What about “Agile”? ● How about being agile? ● Why not we keep dynamic balance between efficiency and effectiveness
- 6. Agile mindset ● It’s all about ”Mindset”. ● Fixed Mindset vs Growth Mindset ● The courage to ”Experiment and Attempt"
- 9. Scrum ● Transparency, Inspection, Adaptation ● Commitment Focus Openness Respect Courage ● Developers Productor Owner Scrum Master ● The Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective ● Product Backlog, Sprint Backlog, Increment
- 10. Running Scrum ● Transparency, Inspection, Adaptation ● Commitment Focus Openness Respect Courage ● Developers Productor Owner Scrum Master ● The Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective ● Product Backlog, Sprint Backlog, Increment Theory: Courage Team: Openness, Respect Events: Focus Values: Practice Artifacts: Commitment Mindset Execution Operation Effectiveness and Efficiency
- 11. ProductDiscovery effectiveness ● Productive & Valuable ● Facilitation & Collaboration ○ Lean Canvas ○ User Journey Map ○ Impact Mapping ○ User Story Mapping ○ Focused Conversation ○ Consensus Workshop ● Head in to “Product Delivery”
- 12. ProductDelivery efficiency ● Quality & Velocity ● Practices & Tools ○ BDD, ATDD, TDD ○ CI, CD ○ Mob programming ○ Test Automation ○ Profiler, Debugger, IDE, Infrastructure as code ● Head in to “Product Discovery”
- 15. Domain driven ● Domain: an area of interest or an area over which a person has control ● Problem and Solution in domain ● Domain-Driven rather than Data-Driven
- 16. Domain driven design ● Collaboration ○ Domain Experts Developers ● Ubiquitous Language ○ We are on the same page ● Domain Modelling ○ Process Oriented ○ Problem Space and Solution Space ○ Architecture
- 17. Domain driven design ● Strategic Modelling 戰略設計 ● Tactical Modelling 戰術設計
- 18. StrategicModelling ● Problem Space ○ Working on the solution to a problem ● Domain、Subdomain ○ Logic in the business flow ● Bounded Context ○ Value stream in the process ● Context Mapping ○ Mapping value stream source: Implementing Domain-Driven Design EC
- 19. TacticalModelling ● Solution Space ○ Working on the solution implementation design to a problem. ● Architecture ○ Layered by Business process , logic and infrastructure ● “Working” Objects ○ Responsibility ○ Objects flowing ● Event trigger ● Pattern design
- 20. DDD Practice Technique ● Event Storming ● Domain Storytelling
- 21. BaseonBusinessProcess Multi-level Approaching • Big Picture, Domain Model • Process Modeling • Software Design, Implementation Model
- 22. Source: https://www.researchgate.net/figure/Discovery-Delivery-Cycle-based-on-17_fig2_345449904 價值 認定 價值 選擇 Big Picture 價值 釐清 Big Picture Big Picture Process Modeling 價值情 境假設 Strategic Tactical Strategic Strategic 實作價 值對應 實作 品質 實作 速率 Process Modeling Strategic Implementation Model Process Modeling Strategic Tactical 實作 彈性 Implementation Model
- 23. 拉麵道 Requirements A. 拉麵店老闆: • 1. 早上 09:00 要到店開門,並且先檢查生麵的狀況,然後查看叉燒的入味程度。 • 2. 接著要查看店內庫存,是否需要叫貨 • 3. 早上 10:30 把門打開,開始今天的營業 • 3. 下午 14:00 要把門半關,休息 3 小時 • 4. 下午 16:30 要開門準備接晚上的生意 • 5. 下午 17:00 通知外場人員要開始接晚上的顧客 • 6. 從冷凍冰箱中拿出叉燒退冰,並且準備好滷鍋的滷汁 • 7. 晚上 21:00 要準備結算今天營業額 • 8. 要通知外場不要再接顧客進來 • 9. 晚上 21:30 關帳,結算今天營業額 • 10. 每月 20 號以前的營收,都入小庫;20 號當天要入大庫 • 11. 結算完的營業額要輸入到系統中 • 12. 把店門半關,指揮員工進行店內的清潔 • 13. 將麵團放到發酵機中發酵 • 14. 把叉燒放入滷鍋中 • 15. 將滷叉燒的滷鍋放到冷藏冰箱中 B. 外場人員: • 1. 早上 09:00 到店打卡,開始清掃外場的地板 • 2. 店內擦拭桌面和清洗地板 • 3. 如果老闆昨天有叫貨,要幫忙老闆進貨和點貨 • 4. 把碗櫃裡的碗和筷子拿出來洗過一次 • 5. 將洗好的碗筷架好晾乾 • 6. 早上 10:30 開始接待顧客 • 7. 當店內還有位置的時候,要把顧客迎接進店;如果沒有,則要請客人排隊 • 8. 將入場/排隊顧客帶位到指定座位 • 9. 從口袋中拿出並撕下一張點菜單給顧客 • 10. 如果顧客很快就點完了,就把點菜單夾在訂單架上 • 11. 當內場人員煮好指定顧客的料理時,會被內場人員通知 • 12. 將料理端到指定客人的座位桌上 • 13. 當客人用完,要收桌和清洗桌面 C. 內場人員:
- 25. Problemspacetosolutionspace • DDD 協助專注於解決 複雜的領域問題。 • 協助達成一致的理解， 發掘與實作合適的解 決方案。
- 26. essential or accidental ● Essential complexity: 來自於領域，即問題本身， 它們無法被消除，除非縮小 問題的範圍。 ● Accidental complexity: 解決方案本身所引起。 WhataboutComplexity
- 27. dealingwith complexity ● The rule of thumb: ○ 擁抱 essential complexity ， 或者稱為 domain complexity，消除或減少 accidental complexity 。 ○ 作為開發人員的目標是不要引 入過多的 accidental complexity ， accidental complexity 常常是由於過度 設計導致。
- 29. Thank you!