DDDesign Taiwan 2023 Conference - 單兵作戰

在這次的分享，面對一個陌生的領域，一個工程式要如何使用 Domain-Driven Design 的戰略概念，去理解並切入當前系統流程與發現痛點。

並在後面分享在不正確的時間點，作交付價值以外的項目，造成延遲交付的問題。

Transcript

1. 單兵作戰: 以領域驅動設計 (DDD) 改善既有進銷存管理系統的策略與 實踐 Ean 2 0 2 3 / 0 9 / 1 7 0
2. 1 在軟體開發大洋中漂流的小小竹筏，關注各種架構與 技術的發展，並持續探索技術與業務價值的平衡點。 目前專注於探討雲端資源、容器化與監控的統整，在 支撐業務價值的同時，有效降低建置/營運成本、並系 統的可靠性。 - DDD 社群志工 - 後端工程師 Blog: 伊恩的開發狂想 ( https://eandev.com )
4. 故事的起源 3 > 15 y • 查詢時間過久。 • 功能不符使用，流程中需要人力介入。 • 景氣不好，不易請人。 五金雜貨材料行
5. 使用現行的解決方案 4
6. 但是失敗了 5 ✓ 建置費用高昂，需另外購買硬體。 ✓ 無法有效協助資料轉換。 ✓ 操作流程變動過大。 ✓ 常用/需要的功能，需要另外購買或客 制。 ✓ 操作複雜，不直覺。老員工無法習慣
7. 6 尋找另外的解決方案
8. 提出的需求！背後的痛點？ 7 我需要的功能有 ⚫ 廠商叫貨單的併單 ⚫ 電滙記錄的建立與查詢 ⚫ etc. 想要這功能的原因？ 要解決什麼問題？
9. 身為該領域小白要如何地切入？ 8
10. 與領域專家請教 9
11. 取得共識 10 https://domainstorytelling.org/ https://www.eventstorming.com/
13. 12 https://domainstorytelling.org/ • Actor • Work object • Activities • Annotations
14. 由大而小的釐清現有流程 13 整個流程 特定流程 流程細節
15. 在現有流程中找出解決痛點的做法 14 收到 訂購單 記錄 待採購品項 合併 採購單 建立 採購單 與供應商 下單 進貨清點 款項匯款
16. Bounded Context 15 單據管理 庫存管理 供應商/客戶 管理 帳務管理
17. 服務與 Bounded Context 的關連 16 單據管理 庫存管理 供應商/客戶 管理 帳務管理 原有系統 擴展服務 痛點： 匯款資料管理麻煩 採購時需要額外進行併單
18. 17 • 老員工已習慣現有系統，在新系統無法完全取 代現有系統前，老員工維持使用原有系統。 • 兩套系統並行，所以使用上必須避免斷層感。 • 原先系統的資料庫不可以進行修改。
19. 流程整合 18 現有系統 建立採購單 建立訂購單 建立進貨單 現有系統 新建系統 建立採購單 建立訂購單 電滙記錄 建立進貨單 建立採購單 建立請購單
20. 架構演進 19 Legacy System Origin New Read-Only service service Web Read-Only service New service Web service service Origin
21. 約定交付方式 20 Phase 1: 滙款記錄與查詢 Phase 2: 請購單/採購單 Phase 3: 訂購單 ……
22. Phase 1: 滙款記錄與查詢 Phase 2: 請購單/採購單 Phase 3: 訂購單 …… 結果 Delay 21 架構調整 重覆造車 !? 範圍過大
23. 調整軟體架構的時機點不對(一) 22 Origin New Read-Only service service Web Read-Only service New Read-Only service service Web Read-Only service Origin GW
24. 調整軟體架構的時機點不對(二) 23 單一用戶架構 多租戶架構
25. 原有資料的直接引用？或是再造? 24 Origin New Read-Only service service 廠商資料 廠商資料 直接使用現有資料 後續搬移系統時，需要調整資料 系統的設計會遷就資料結構 需實作資料管理介面 後續搬移系統時，無需再異動。 系統設計靈活性高
26. 交付軟體範圍與過度設計 25 最快可以解決使用痛點的版本 時間 操作體驗優化 過度設計或實作順序安排不當
27. 工程師的浪漫 vs. 業務交付 26
28. • 同一張單據，在不同 BC，對應的名詞與意義，可能截然不同。 • 實例化需求(SBE)是對焦使用情境的好東西，但若直接以測試角度出發，會吃到意想不到的苦頭。 • 就算已經事先討論好，但交付出去的軟體，使用者還是會有意想不到的操作。 • 規劃交付範圍的時候，可以快速解決用戶痛點的最像 MVP 為基準，進行後續的迭代交付。 • 功能實作順序，可以依最終使用環境來進行安排。 一路過來的感想 27
29. 28 Fin