DDD架構設計
•Download as PPTX, PDF•
12 likes•2,990 views
This slide presents some famous architectures and how to use DDD to implement system and choose which architecture is more appropriate.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to DDD架構設計
Similar to DDD架構設計 (20)
More from 國昭 張
DDD架構設計
- 1. DDD架構設計
- 2. 大綱 • 架構原理 • 分層架構 • 商業邏輯層的實現模式 • 微核心架構 • 事件驅動架構 • 服務導向架構 • 大型系統架構實務分析 • 回顧
- 3. 軟體架構(Software Architecture) 軟體架構設計聽起來是 一門很厲害的學問,它到 底是什麼? • 軟體架構是一種樣式(Pattern);它由許多軟體開發 人員的經驗所找出來的一種設計樣式 • 由於它是樣式,因此,沒有固定的程式碼撰寫方式 • 學習曲線較為陡峭
- 4. 樣式(Pattern) 我知道它是樣式了,但是 什麼是樣式? • 樣式是在特定的上下文中反覆出現的現象或是 行為動作 • 每個樣式帶來好處的同時也會附加它的負面效應 • 要注意樣式是有其特定的上下文的,不是任何情境 都可以直接套用
- 5. 起點(Begin) 太棒了!那我要從那裡 開始學軟體架構設計? • 先從分層開始學起 • 絕大多數的架構都是由分層架構演化而來的 • 分層架構是現行較多數開發人員所使用的架構
- 6. 分層架構(N-Layer Architecture) • 分層架構是所有軟體架構的基本雛型 • 每一層都只能呼叫自己位置的下層的元件; 不得直接呼叫非自己直屬的下層的元件 • 嚴格分明的階級讓元件的管理有了初步的 觀注點分離
- 7. 分層的意義(meaning) 為什麼要遵守這堆奇怪 規矩,有什麼好處呢? • 就像是遊戲規則一樣,所有人都遵守遊戲規則 整個活動才能夠繼續進行下去 • 分層可以帶來關注點分離;讓偵錯和程式碼的 維護變得更加容易 • 讓不同職責的程式碼放置在它既定的位置,這 種方式就是分層
- 8. 該怎麼思考分層 分層的概念以了解,但是 實作上,常常不知道該怎 麼決定,那些要放在同 一層? • 實作上,會先預定義一個初期的分層層數 • 當開始撰寫類別程式碼時,會依照它的功用/職責 來決定它應該放在哪一層 • 唯一準則就是”單一職責”,否則會導致混淆,不知道 該將類別放在哪一層
- 9. 單一職責(SRP) • 每一個類別都該只擁有一個職責 • 分層架構中的每一層都應該只擁有一個職責 • 類似工作的類別就應該放在同一個層中
- 10. 分層架構範例(Sample) • Presentation層: 處理所有介面展示以及與客戶(Client) 的互動 • Business層: 負責處理請求對應的業務 • Persistence層: 處理所有與資料庫層交互的工作 • Database層: 儲存物件狀態資訊的地方,可以是各種 存儲方案
- 11. 封閉性(Closure) • 每一層都是封閉的,因此,請求(Request)需要按順序從 Presentation層一路傳遞到Database層 • 層的封閉性保障了層與層之間的隔離性。 • 層的隔離性對於程式碼的可維護性是一大幫助
- 12. 實務(Practice) • 由Presentation層接收到客戶的請求,接著,它會委派 給一個元件;該元件可以找到Business層中可以 與之交互的元件 • 業務層在收到請求之後若有資料相關的操作需求, 它會創建Persistence層中相對應的元件 • Persistence層元件與Database層交互後的成果會回應 給Business層的元件;爾後,一路回覆給上層元件,直到 Presentation層
- 14. 學為分層後的下一步(Next Step) 分層架構已經懂了,下一 步該學些什麼呢? • 學會了分層架構之後,已經有了基本軟體架構的 基礎知識 • 下一步要學習是”硬體”方面的分層架構
- 15. 分層架構-硬體(Hardware) • 除了在軟體的部份有分層之外,硬體的部份也需要進行分層 • 硬體分層架構另一個常被使用的名詞-系統架構;主要由系統架構師負責設計 • 系統架構與軟體架構同樣重要,而且兩者在設計需要相互搭配 友善鏈結
- 16. 系統架構的核心概念(Concept) 感覺起來和軟體分層很 相似,但是系統架構的 核心概念是什麼? • 多層若以Multi-Layer,則意味著是在討論軟體方面 若是Multi-Tier,則意味著是在討論硬體方面 • 系統架構需要對作業系統、網路、安全、儲存體 有高度的瞭解與熟悉 • 架構師不僅要瞭解軟體架構,也得瞭解系統架構
- 17. 常見的架構 有沒有那種架構是大家 常用的? • 因為Web系統的流行,其中有一種架構最常 被開發人員所應用-MVC • MVC這個架構由於常被使用,因此,在不同的 程式語言中有著各種不同MVC架構實現的 框架 (ASP.Net MVC, SpringMVC…)
- 18. 名聞暇爾的MVC架構 • MVC是”前端”的架構設計 • MVC由三個主要的元件所構成: • View • Controller • Model • 妥善的職責分離,讓畫面的呈現變得更加有效率
- 20. 適用性(Appropretely) MVC是”前端”架構!?架構 還有分前後端? • 每種架構都有其適用的地方,不能隨意亂套用 • MVC就是為了讓資料呈現有更好的表現而被 挖掘出來的 • 回想系統架構,那些負責資料/畫面呈現的系統 就可以考慮採用MVC架構進行開發
- 23. 洋蔥架構 • 洋蔥架構是六角架構的進階,在設計的概念上 它承襲了六角架構的”變與不變” • 與六角不同的地方在於洋蔥架構帶入了領域 層的概念 • 洋蔥架構認為領域層是需要維持不變的部份, 其餘部份都是外部易變的部份,需要被隔離 • 核心層部份只允許語言原生的功能,不得添加 外部套件
- 28. CQRS • 詢問不會改變問題的答案 • 將查詢與操作的處理進行拆分 • 應用在資源搶佔型系統 - 演唱會搶票
- 29. 實現(Implement) 架構概念懂了,那該怎麼 實做各個層呢? • 每個層的實做都有其方法論與框架可以參考 • 由於框架的豐富程度極高,因此,很多時候開發人員 專注會放在商業邏輯層 • 表現層- MVC框架的View, 或是SPA • 應用層- MVC框架的Controller • 資料存取層- Entity Framework
- 30. 商業邏輯層的實現模式 • 在Martin Fowler先生的著作: PoEAA中,詳細剖析了 幾種商業邏輯層的實現方法: • 交易腳本 • 表模組 • 領域模型-貧血模型 • 領域模型-富血模型 • 每一種實現方法都有其優點和缺點以及適用的場景 是PoEAA不是PPAP!
- 31. 交易腳本(Transaction Script) • 大多數的應用程式可以想像為一系列的交易。一個交易 可以查看以一定方式組織的訊息 • 每一個交易都有它自己的交易腳本,每一個交易腳本都是 一個類別的公有方法 • 每一個交易腳本都是採用程序導向的開發思維;處理來自 Presentation層的單一請求(Request)
- 33. 表模組(Table Module) • 以一個類別來應對資料庫中的一張資料表、視圖(View) • 除了屬性完整對映之外,還會有相關商業邏輯的處理 • 當系統功能越來越豐富後,可以發現到類別的方法變的 更多
- 35. 貧血模型(Anaemic domain model) • 領域驅動所分析出來的模型,但是每個模型所對應的 類別僅只有getter/setter,而沒有商業邏輯的方法 • 通常與ORM的框架一起應用 • 實做上會將商業邏輯方法額外放在另一層(Service),而 這個服務層可能會採用交易腳本
- 37. 富血模型(Rich domain model) • 富血模型的模式就與DDD中所定義的戰術技術一致了 • 每一個模型中的類別都擁有商業邏輯,並且會依照通 用語言的定義去實做
- 39. 交易樣式(Transaction Pattern) • 從某一個使用案例作為分析的項目 • 找出使用案例主要要處理的工作(Transaction) • 該工作必有細項(Transaction-LineItem) • 工作細項可能會使用到的額外物件及其描述 (Item, SpecificItem) • 紀錄參與工作的人員和地點(Paticipant, Place) 友善鏈結
- 40. Participant Transaction Place Transaction LineItem Transaction Subsequent Transaction 交易樣式 • 客戶-訂購(Customer-Order) • 客戶-銷售(Customer-Sale) • 學生-註冊(Student-Register) • 商店-銷售(Store-Sale) • 飯店-訂房(Hotel-Reservation) • 銷售-銷售細項(Sale-Sale LineItem) • 訂購-訂購明細(Order-Order LineItem) • 出貨-出貨明細(Shipment-Shipment LineItem) SpecificItem Transaction • 購物-付款(Shopping-Payment) • 訂購-出貨(Order-Shipment)
- 41. SpecificItem LineItem Item LineItem Item SpecificItem 交易樣式 • 具體特定的收銀機-銷售(Specific-Register-Sale) • 具體特定的銀行-存款(Specific-Bank-Deposit) • 錄影帶-出租細項(VideoTape-Rental LineItem) • 具體特定的產品-訂購細項(Specific-Product-Order LineItem • 項目-交易細項(Item-LineItem) • 項目-出貨細項(Item-Shipment LineItem) SpecificItem Transaction • 產品規格-產品(Product-Specification-Product) • 影片型錄-錄影帶(Video-Description-Videotape)
- 42. 四色原型(4-Colors Prototype) • 以四種顏色描述不同的重要性: • 紅色: 時間 • 綠色: 人、地、物 • 黃色: 角色 • 藍色: 描述
- 44. 四種實現方式的分析(Analysis) 四種模式的好壞和使用 時機? • 四種模式彼此沒有優劣,只有適用時機的差異 • 有些情境下甚至可以同時使用四種中的某幾個 • 四種模式在實現上有成本的差異,對於核心子領域 的限界上下文,建議採用富血模型
- 45. 活動紀錄(Activity Record) 我還知道另一種方法, 叫做活動紀錄呦! • 活動紀錄是表模組的變異版本;它是將資料表中 的一筆Record對應到一個類別 • 活動紀錄同樣也會將商業邏輯放在Record對應 的類別中 • 兩者同樣都犯了”God Object”的設計謬誤
- 46. 其他架構 除了分層式架構之外,還 有什麼其它的嗎? • 架構的分類可以粗略分為: • 分層式 • 微核心 • 事件驅動 • 服務導向 • 響應式
- 47. 微核心架構 • 又被稱之為”插件架構”;主要功能和業務邏輯都是透過 插件來實現 • 核心通常只包含系統可運行的最小功能 • 插件之間的通訊,應該盡可能降到最低,避免出現相互 依賴的問題
- 48. 微核心架構 • 每個插件都不能彼此直接溝通,需要透過微核心進行 溝通 • 微核心不需要做太多事,只要專職在基礎的IPC (Internal Processor Communication)
- 49. 微核心的應用 微核心多半是應用在那 裡呢? • 由於本身無法進行水平擴展,可與其它架構合併使用 或是應用在一些特定需求的元件上 • 需要新的業務功能可以直接開發一個新的插件 • 核心本身的開發具有一定難度,需要涉及到插件的 通訊、登記…等等,這些低階操作的處理
- 51. 事件驅動架構 • 屬分散式非同步架構的一種應用,具有高伸縮性和適應性 • 元件會在本身狀態變更之後,發布事件 • 具有兩種拓樸結構: Mediator / Broker 元件 事件5 事件4 事件1 事件2 事件3 元件 追加 讀取 發布給訂閱者 事件流
- 55. 事件溯源 曾聽說過事件溯源,這個 和事件驅動架構有關嗎? • 事件溯源(Event Sourcing)是一種開發思維上的突破; 它將物件每次狀態的變化都紀錄下來 • 事件溯源具有能夠修復物件錯誤的狀態變更,或者是 回放物件的狀態變化
- 56. 事件溯源(Event Sourcing)架構 • 每當物件的狀態改變時,都會產生出一個可追蹤的事件 • 系統會儲存每一個物件的事件到儲存體中 • 當系統重新取回物件時,會將其所有的事件取出並呼叫 物件的”狀態事件套用” 方法,讓其回復到最後一次狀態的 變更 物件 事件5 事件4 void Apply(IEvent e) State.Mutate(IEvent e) Changes.Add(IEvent e) 事件7 事件6 查詢狀態
- 57. 事件驅動 & 事件溯源 這兩個似乎都與事件 有關,但是好混淆? • 事件驅動架構更偏向是概念,而事件溯源是一種 實現的方式 • 事件驅動的描述會著重在如何將事件以非同步 的方式交由事件處理器進行處理 • 事件溯源著重是在以事件建構出物件,與原先的 事件驅動有些著重點上的差異
- 58. 事件溯源的缺點與補強 事件溯源可以做到這麼 厲害的功能,它有沒有 什麼缺點? • 事件溯源由於是將物件狀態的變化完整的紀錄 因此,其資料儲存的格式上較偏向”非正規化” • 要想從事件溯源的探勘資料其實是非常困難的, 因為儲存的目地並非是為了這個項目 • 要想解決這個問題只能和其他架構結合-CQRS
- 59. CQRS與事件溯源 • Event Sourcing不利於製作報表,因此, 若能夠與CQRS配合,就能夠解決這個問題 • Command的部分採用事件溯源,而Query的 部分則採用不同的儲存格式 友善鏈結
- 61. 服務導向架構(Service Orientation Architecture) • 採用”服務累增”的概念進行開發 • 服務依顆粒度進行分類;粗顆粒度的服務是採用 組合的方式進行開發 • 組合的資源有: 服務、流程、處理元件
- 62. 企業服務總線(ESB) • 可以使用ESB將各個不同的服務整合在一起 • 使用BPEL/BPMN定義業務流程,組成新的服務 • ESB可以提供服務的註冊和路由,並且讓各個服務 能夠以低耦合的方式進行整合
- 63. 服務導向的問題 感覺SOA很完美,它是最終 的架構解決方案? • 要開發服務導向的系統,需要所有團隊的成員都 瞭解SOA的核心精神與開發流程 • 服務的自治能力是很重要的,而不是單純地開發 一個曝露端點的Web服務 • 建構SOA是有著一定的複雜度,這樣的成本是否 低於它所帶來的優勢?這需要詳細思考
- 64. 服務導向的再演化 SOA從推出到現在已經有 一段時間了,有再改善或 是演化嗎? • SOA的複雜度是它最大的問題,只要最大限度的 降低複雜度,就能夠讓SOA更能夠讓人接受 • SOA的複雜度來自於兩者: • 服務顆粒度難以掌握 • 以流程工具整合服務,以產生新的服務
- 65. 微服務(MicroService) • 微服務排除多層式架構的問題 • 每個服務都是最小且單一職責 • 每個服務都可以獨立部署
- 66. 微服務 & SOA 微服務就是SOA的改進 版本嗎?如果不是,那他們 差在那裡? • SOA是一種架構樣式,而微服務則是架構風格 (與RESTful概念相同,皆是一種架構風格) • 微服務也是一種服務導向的思維,但是它並不 全然遵守SOA的所有規範
- 67. 微服務的概念 • 每個服務都像是一個個的元件,每個元件都會 提供服務端口給彼此 • 由User Interface層進行服務的整合 • 若服務之間有很高的相依性,會影響到效能
- 69. 單片式的問題 • 擴充: • 當團隊想要擴充(Scale)系統,只能將全部服務都一齊擴充 • 提升: • 底層框架(Framework)的升級可能會有問題;某些功能可能會出狀況 • 寄託在單一技術堆疊: • 當已選擇某個技術堆疊進行開發,事後難以再改變 • 泥淖: • 有發現任何設計上的錯誤,只能採用替代方案(Workaround)
- 73. 分散式系統溝通方法分析 One-to-One One-To-Many 同步 Request/Response - 非同步 Notification Publish/Subscribe Request/Async Response Publish/Async Response • 同步: 當Client發出API呼叫之後,在等待回覆期間會被阻斷其它操作 • 非同步: Client發出API呼叫之後,在等待回覆期間不會被阻斷其它操作 • One-to-One: 一個Request給指定的Service進行處理 • One-to-Many: 一個Request交給多個Service進行處理 • Notification: 射後不理 • Publish/Subscribe: 節點發出訊息通知訂閱該主題的其它節點 • Request/Response: Client發出請求,並期待服務的回覆 • Request/Async Response: 與Request/Response訊息交換模式相同,但是在等待服務的回覆時, 並不阻斷其它操作
- 74. 綜合應用
- 75. 服務探索 這麼多服務怎麼找到 那一個是我要的? • 常用的策略是兩種角度切入: • Client端 • Server端 • Client端的思維是去查詢服務註冊器,並且由Client 自行設計負載平衡演算法 • Server端的思維是製做一個Router;它可以協助Client 的Request找到它需要的服務
- 77. CAP理論 • Consistency代表資料一致性,也是資料庫交易最 在意的要素之一 • Availability代表使用者何時何地都能夠操作系統 • Partition Tolerance代表著在某些節點異常的狀況下 是否仍能夠正常地運作 • 大多數系統開發會傾向選擇AP,而一致性的部份 則採用最終一致性 擴展性不大 效能不高 一致性不穩
- 78. 分散式交易-兩階段提交 友善鏈結 TC(交易協調器) 資料庫A 資料庫B • 兩階段式提交是常見的分散式交易手法 • 缺點在於效能不佳,且需要一個交易協調器
- 79. 分散式事件交易處理 如果是要符合CAP理論 而採用最終一致性,有 其他做法嗎? • 若是能夠接受最終一致性,可以考慮採用事件驅動 的思維來解決問題 • 每個服務在完成自己本地的交易之後,發出事件給 其他服務;其他服務收到事件之後,也同樣進行本地 交易(可選擇採用非Request/Response模式) • 使用中介元件管理(訊息斷路器)也是一種方案
- 80. 訊息斷路器(Message Broker) • 採用事件驅動的模式;利用一個中介元件-訊息斷路器 來協調兩個獨立的服務 • 服務一旦完成一個工作且需要其他服務接著操作時, 服務會發出事件給訊息斷路器;而訊息斷路器,會依照 商業流程去呼叫其他服務 • 服務與服務之間僅對訊息斷路器有依賴,而不會對其 它的服務有依賴 訂房 Svc MB 客戶 Svc Order Created Order Created Credit Reserved Credit Reserved Credit Reserved Update Room State
- 82. 實務探討(In Practice) 架構我都懂了,有沒有一 些實務例子呢? • 架構並非是在第一手就設計出來,而是由不斷地 演化而成的 • 架構與業務兩者相輔相成;當無法滿足業務時, 技術就該進化,爾後業務就能夠再擴充,以此往復 循環
- 84. 分流與冗餘 先擴展 應用伺服器
- 85. 察覺到使用者的使用模式- 讀寫分離 讀寫分離 • 當運營一段時間之後,會發現應用程式已經無法 再優化,只能觀察資料存取模式來尋求優化之道 • 資料庫有讀取寫入上的比例差異,考量拆分資料庫 • 其實資料庫讀寫分離並無法改善得太顯著 (猜猜看為什麼?)
- 88. 怎麼從分析轉至架構設計 我已經全部了解架構,關 於分析到架構設計的過 程是甚麼? • 從需求蒐集開始,接著採用DDD戰略分析系統 • 子領域、限界上下文,這些都是要先掌握的技術 • 有了限界上下文的整合概觀之後,就算是有了架構 的雛型版本了
- 89. 第一步-分析出子領域和限界上下文 • 藉由DDD先分析出子領域 • 分析是否存在核心領域 • 針對每一個子領域都先分配一個限界上下文
- 94. 下一步? 再來是不是就要進入 DDD的戰術技術了? • 接下來就是下卷要討論的DDD戰術技術 • 在戰術技術中將逐一討論各個項目的實作 • 要注意架構需要隨時重新審視並且調整
- 95. 回顧 • 分層架構- • 軟體分層架構(Multi-Layer) • 硬體分層架構(Multi-Tier) • 架構有其適用的場景,不能隨意套用 • 微核心架構擴充性高,但不利於擴展 • 事件驅動的擴充高,但學習門檻高 • 事件不等於紀錄(Log) • 事件溯源是一種事件驅動的實現 • 架構是演化而來的,不是設計來的 • 由DDD分析取得架構雛形;再決定用使用哪一種 架構來實作