Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie 2020 11-27 Taiwan DDD Conference
Ähnlich wie 2020 11-27 Taiwan DDD Conference (20)
2020 11-27 Taiwan DDD Conference
- 1. DDD in Requirements 黃冠融, PMP, PMI-RMP, PMI-PBA, PMI-ACP, A-CSM, CSPO Octaltysis Prime, Software Engineer
- 2. About me • 在 Octalysis Prime 擔任 Software Engineer • 之前在一家 SI 公司（拓墣龍科 技）擔任工程師，現在是該公 司的顧問 • DevOps Taiwan volunteer. • Gamification Advocate.
- 3. 議題演講方向 • 需求的重要性 • 工程師軟體開發的世界是什麼 • DDD 與其他知識的結合
- 4. 專業經理人 的困境 • 軟體需求的複雜度日漸提升 • 了解需求 • 建立軟體資料模型與關聯 • 辨識相關任務等 • 建立 UI/UX 並測試 • 確認東西是否貼近使用者
- 6. 有哪些需求 類型 • Business Requirements • Stakeholder Requirements • Solution Requirements • Transition Requirements • Project Requirements • Quality Requirements
- 7. 我們如何造 成鴻溝 • 每個人對於領域知識可能只知片段 • 用詞、業務往來的環境不同 • 太多的行話 technical jargon
- 8. 傳統的分工 角色 • End User • Product Manager • Project Sponser • Project Manager • System(Business) Analyst/Desginer • Developer/Quality Assurance • Operator
- 9. 不同產業的 轉換 • Ex: Buyer vs Anchor • Ex: 資安的 CM vs 專案管理的 CM
- 11. 大致的流程 • 掌握有關領域知識1 • 辨識 subdomain2 • 設計一個 Rich domain model3 • 告訴 model 裡面的內容要做什麼4
- 12. DDD: 一個解決上述問題的手法 • 利用 patterns 和 principles 解決複雜問題 • 有著不在少數的複雜專案成功案例 • 軟體開發與實務與個人經驗可以一致 • 簡潔、可測試的程式碼來代表著這個領域知識
- 13. How? • 與領域專家互動 domain model • 一次為一個 sub-domain 建模 • 實作 sub-domain
- 14. 關於管理系統的 Domain
- 15. Play in one act • 學生向教練預約課程 • 課程有可能是團體課程或是私人教練 • 課程可能要求器材的使用、或是空間 • 上課時也要關注到是否有場地、器材可以使用 • 教練會根據（或）場地是否可使用決定當日的訓練行程 • 不同的訓練類型與行程會有不同的器材與場地
- 16. Ubitiqous Language • 解決沒有共同語言的壞處 • 解決客戶提供的需求與架構間的拼圖遊戲 • 會持續更新甚至定稿後作為本次專案的標準名詞
- 17. Ubiquitous Language • 特定領域的單字，可以是名詞、動詞，甚至副詞。 • 最好由所有專案（或產品）的參與者共同擁有。 • 用以統一文件或是說明的內容。
- 18. Ubiquitious Language 用在哪裡 • User story 或 RFC • 任意的會議 • 書信往來 • 技術文件 • 流程或是行程 • 程式碼
- 19. Use the model as the backbone of a language.
- 20. Play in one act • 學生向教練預約課程 • 課程有可能是團體課程或是私人教練課 • 課程可能要求器材的使用、或是空間 • 上課時也要關注到是否有場地、器材可以使用 • 教練會根據（或）場地是否可使用決定當日的訓練行程 • 不同的訓練類型與行程會要求不同的器材與場地
- 21. Notice • 課程是個 domain name • 學生的同義詞：如學員、被訓練者，都不會被這個領域接受
- 22. Missing a point is creating a bug.
- 24. Bounded Context • 什麼該在問題領域內，什麼要在外 • 發展 Context Map
- 25. 什麼是 Bounded Context • 不同範圍的 elements 都有自己的明確含義 • 超出此這個範圍的內容，其對應的語言就不同 • 商業領域被切分成若干領域後相連，每個領域有自己的實作
- 27. Context Maps • 類似於地圖上的圖標說明 • 對照於前一張圖，我們要解釋 Student 在預約課程與金流的差異 • Ex: Student 在預約課程只要提供 Name • Ex: Student 在付款金流卻要 Name、信用卡卡號、Email 等
- 28. Layers in Software • 傳統式 3-tier 架構
- 29. 表現層 • Task-based • Device Friendly • User Friendly • 滿足真實世界的使用過程
- 30. 應用層 • Application 的 use cases 實作 • 將運算的資料結果回傳給表現層 • 統整所有表現層元件的任務 • 與表現層是雙向鏈結的
- 33. Domain Logic is all about business rule into the code
- 34. Domain Layer • 實作商業規則與組織商業邏輯的地方 • 包含 Domain model，Domain Service
- 36. Domain Model 在 Domain Layer 中，與 Domain Service 互相連結
- 37. Business Domain thinking is not like… • 只是物件模型 • 資料庫只是部分基礎設施，可以被忽略 • 統一語言的應用是引導我們作為物件模型的命 名
- 38. 應該是 物件 • Context mapping • 透過物件 Modeling 只是一個方法 忽略資料庫 • 要思考物件能否容易 被儲存 • 儲存體不是重點，但 還是要思考這部分 • 主要的關注還是回歸 到 business domain 統一語言 • 了解領域的每個用詞 語句 • 商業語言與程式碼要 一致
- 39. 資料為中心設計？？
- 40. It’s all about behavior.
- 41. 行為 • The way in which one acts or conducts oneself, especially towards others • 檢測物件狀態是否合法的 method • 對某物件執行商業行為的 method • 表達商業物件處理流程的 method
- 43. 所以主要不是特徵或是資料 • 預約的時間 • 教練的姓名 • 場地編號 • …
- 44. Domain Model as a Domain API • 在實作 Domain model 時，以 api 的形式開發 domain model 的行為 • 可以利用一個實例測試，將 domain model 與領域專家 討論
- 45. Domain Model as a Domain API
- 46. Domain Service • 協調聚合和儲存體的活動，用以實作業務行為 • 可能會與 infra 相關的服務互動，例如寄信或傳送文字 訊息等
- 47. Domain Service in depth 在 Domain service 中的 actions 都是來自於 需求並且被領域專家認可 Domain service 中的任何命名都與統一語言 一致
- 48. Domain Service • 一個好的 Domain Service 會有以下特性： • 不是 Entity 或 Value Object 的獨有的 behavior • 會根據其他領域模型來定義介面 • 無狀態，但可能有 side effect • 通常是核心應用
- 49. 我們的管理系統的 Service UI • 即時通訊處 理 • JSON parsing Domain • 訂單處理 • 會員加值 Infra • 郵件寄送 • Logging Service
- 50. Events in Business Domain • Event 會影響整個系統架構 • Event 用來知道系統的狀態 • Event 或者是紀錄
- 51. Event Soucring • 確定所有 Application 狀態的改變都能得被記錄到
- 52. 健身房的預約 Event • Add Appiontment 1 • Add Appiontment 2 • Update Schedule info • Update Classroom info • Remove Appiontment 2 • Add Health info
- 53. Event Soucring • 事件只會成為歷史 • 事件代表著統一語言的表達 • 通常使用過去式表述（過去發生） • Event 會儲存到 Persistent 中 • No delete, Appended-only • 某個已知狀態的快照
- 54. Our Events • 在我們的 Process Order Service 中，要有哪些 Events？ • 在我們的訊息處理，要做哪些事情？
- 55. Work with legacy code • 遺留程式碼的簡單要素 • 可以運作的程式 • 但你不是很喜歡或是可能不該這樣撰寫 • 難以修改
- 56. Legacy Code as a Service • 從頭開始以抽象的概念重寫 • 在執行重寫的工作時，使用現有的資產作為服務(微服務概念) • 在遺留系統加入一個介面作為 Façade，以這個 façade 來進行溝 通
- 57. Work with UX 好的點子都是從視覺草 稿開始畫起… What You See is What you get See Is user interface Get is User experience
- 58. 然而 UX 在 DDD 中 • 好的 UX 通常會專注在使用者的操作流程、介面等等 • 可能一個完整的畫面牽涉到好幾個 Business Logic • 這使得 UX 和 DDD 似乎難以互相配合
- 59. UX Workflow • UX 的責任 • 可以透過 flowchart 了解最基本的商業邏輯
- 60. Flowchart 的好處 • 決定 input/output 內容與 view model class 要有什麼 • 可以讓 Application layer 的端點接收/回傳 DTO class • 讓 Application layer 協調不同層次的任務
- 61. CRUD 就足夠了嗎？ • CRUD 是 • Create • Read • Update • Delete
- 62. CRUD 帶來 • 資料庫中心的思維 • 沒有追蹤的機制 • 有限的特色 • 不多的商業邏輯 • 同步併發有困難 • 相依性過低 • 雖然可以快速實作，但實際運轉起來不切實際
- 63. 簡單的解決辦法(但可能沒有效) CREATE (作為 ENTITY MODEL 使用) READ (展出 VIEW MODEL) UPDATE、DELETE (紀錄變更 的狀態)
- 64. Q&A
- 65. Thank you!
Hinweis der Redaktion
- 電文在資訊界的意義 vs 銀行的 swift 電文。
- 簡易的商業知識學習流程大致如下
- 需要建立模型才可以讓大家知道關注的商業領域內有哪些語言或使用者的行為等等
- 錯誤的理解或是變數命名都容易引入 bug
- Subdomain = problem space => room Bounded Context = solution space => Carpet, floor Carpet, floor 都是要讓 room 可以有個舒適地版的 solution，但你不會分不出來 Carpet, floor 的差異
- 將運算的資料結果回傳給表現層 => serve ready-to-use data in the required form 統整所有表現層元件的任務 => Use-cases of the application’s frontend 與表現層是雙向鏈結的 => 當產生新的 UI ，可能延伸或複製程式碼
- No
- Implement the domain logic that doesn’t belong to a particular aggregate and most likely span over multiple entities. Coordinate the activity of aggregates and repositories with the purpose of implementing a business action.
- DTO（ Data Transfer Object）：資料傳輸物件，Service 或 Manager 向外傳輸的物件。 DTO，用於傳輸資料，可能傳遞給前端，也有可能傳遞給其他系統。用於承載資料。