Ddd(meetup 2) ddd with clean architecture
Download as pptx, pdf3 likes1,286 views
本文探讨了软件架构的基本概念及其重要性，强调在设计中平衡各类架构因子的重要性。讲述分层架构的特点和优势，以及如何在团队中集成领域驱动设计（顿顿顿）以提高软件质量。此外，强调了在架构设计过程中，应当考虑多种维度和原则，以确保软件的可维护性和扩展性。
Ddd(meetup 2) ddd with clean architecture
- 1. 共筆QRCode 1
- 2. DDD with Clean Architecture 軟體架構從0到1 2
- 10. 軟體架構的目標 “The goal of software architecture is to minimize the human resources required to build and maintain the required system.” Robert C. Martin – Clean Architecture minimize 10 前導
- 11. 大綱 11
- 12. 平衡 12
- 17. 選擇主要的架構因子 1st. 架構因子 2st. 架構因子 3st. 架構因子 團隊經過討論和協調 選出三個標的架構因子 17 平衡
- 19. 定期審視架構因子 1st. 架構因子 2st. 架構因子 3st. 架構因子 1st. 架構因子 2st. 架構因子 3st. 架構因子 1st. 架構因子 2st. 架構因子 3st. 架構因子 1st. 架構因子 2st. 架構因子 3st. 架構因子 1st. 架構因子 2st. 架構因子 3st. 架構因子 1st. 架構因子 2st. 架構因子 3st. 架構因子 19 平衡
- 20. 架構的腐化是難以避免 20 平衡
- 21. 因為… 21 平衡
- 24. 分層 24
- 26. 分層架構的特性 ? 上層僅依賴自己的下一層 ? 下一層將運行結果回應給自己上一層 ? 不能跨層呼叫 26 分層
- 27. 為什麼要設計成多層? 27 分層
- 34. 你該怎麼設計？ 34 分層
- 35. 作用力 35
- 36. Vision Planning Strategy Doing Teamwork Consistency Success 產品/專案歷程 真實世界並不美好 36 作用力
- 37. 作用力-團隊歷程 形成期 風暴期 規範期 高效期 解散期 形成期 風暴期 規範期 高效期 解散期 團隊狀態 工作績效 時間 37 作用力
- 43. 作用力-設計歷程 43 作用力
- 45. 45 作用力
- 46. 什麼是你該做的? 46 作用力
- 47. 維度 47
- 48. 回頭思考分層架構 Component + Layer + ? 一維: Component的擴充 ? 二維: Layer的擴充 這兩個維度的思考僅是在 一個系統內 48 維度
- 51. 第四維度-時間 51 維度
- 54. 狀態管理 54 維度
- 57. 商業-商業模型&軸轉 57 維度
- 58. 58 維度
- 59. 59
- 63. 先來看看DRY的描述 “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system” Andy Hunt – The Pragmatic Programmer 63 心法
- 68. 三個近代架構 六角 洋蔥 Clean Domain Model都在內核 68 心法
- 72. 利用三步工作法設計核心領域模型 Capture Embedded Protect Capture: 捕捉領域模型 Embedded: 將領域知識套用到程式碼 Protect: 保護領域模型程式碼不被汙染 72 心法
- 79. 套用DDD的Aggregate模式 79 ? 以Aggregate作為邊界 ? 每個Aggregate中都由多個關係緊密且互相協作的物件所組成的無閉環圖 ? Aggregate必有一個Aggregate Root物件作為Aggregate的封裝 ? 所有與Aggregate的互動,皆是直接與Aggregate Root所提供的方法互動 ? 外部不能直接與Aggregate內部的物件互動! 心法 Aircraft Route Fix 2DPoint Flight Aggregate Root, Entity Entity Entity Value Object Value Object Aggregate: Flight
- 80. Aggregate設計準則 80 ? 一個Aggregate是一個完整的交易(Transaction) ? 當交易所異動到的資料表過於龐大,會造成效能議題(Issue) ? 適當拆解Aggregate(i.e. 不違反交易ACID規範為前題) ? 考慮採用文件型資料庫(NoSQL) 參考資料 心法
- 87. 設計的關鍵概念- Port and Adapter 87 心法
- 88. 與DDD戰術的結合 88 心法
- 89. 兩者結合的實際例子 89 心法
- 91. Clean Architecture的Use Case交互物件 91 個人觀點 ? Clean Architecture中的Use Case物件旨在: 為了完成某個商業目標而指導協作多個 Entity的資料處理流程。 ? 其概念與流程控制的Controller極為相似,但是在Clean Architecture書中的概念圖中,可 以觀察到Controller似乎與Use Case交互物件並不相同。 ? 在推敲下有一個可能,Use Case交互物件: 即為PoEAA書中針對商業邏輯層設計的-Transaction Script ? PoEAA的商業邏輯層設計並非是零和遊戲,亦即可以讓多個一起協作互動,而 Clean Architecture即是合併: Transaction Script與Rich Model “These use cases orchestrate the flow of data to and from the entities, and direct those entities to use their Critical Business Rules to achieve the goals of the use case.” -- Clean Architecture 心法
- 92. 完整的例子 92 心法
- 93. 建議套用Clean Architecture的地方 93 核心子領域 (Core Subdomain) 支持子領域 (Supporting Subdomain) 支持子領域 (Supporting Subdomain) 通用子領域 (General Subdomain) 問題域(Problem Domain) 套用Clean Architecture 的成本,真的太高了! (英文字幕)I need DDD community 心法
- 95. 95
- 96. 96 模式
- 97. 架構模式(Pattern) An architectural pattern is a general, reusable solution to a commonly occurring problem in software architecture within a given context. Architectural patterns are often documented as software design patterns. Following traditional building architecture, a ‘software architectural style’ is a specific method of construction, characterized by the features that make it notable -- by Wiki 97 模式
- 98. 架構樣式(Style) An architectural style defines: a family of systems in terms of a pattern of structural organization; a vocabulary of components and connectors, with constraints on how they can be combined. Architectural styles are reusable ‘packages’ of design decisions and constraints that are applied to an architecture to induce chosen desirable qualities. -- by Wiki 98 模式
- 101. Recap ? 架構的品質因子選三個作為設計的方向 ? 分層架構的知識是架構設計的根本 ? 作用力影響著架構設計的決策 ? 提高思考維度,讓架構完備度更高 ? 領域模型設計三步工作法: (CEP) Capture + Embedded + Protect ? 架構模式與樣式兩者是不同的 ? 內聚力理論指引元件/服務拆分之道 101
- 102. 延遲你的決策,直到你已經準備好 102