ddd(領域驅動設計)之架構總結

1. 分層架構(垂直)前端

  • 分層架構是最基礎的,即好久以前就接觸的mvc,固然書裏說的是基礎設施層,領域層,服務層,用戶接口層;
  • 因這種架構各層之間極易耦合,即頂層依賴底層教嚴重;就引入DI(depency inverse)原則,使得各層之間再也不相互依賴實現,而是依賴接口,實現瞭解耦;抽象不依賴於細節,細節依賴於抽象;
  • DI原則的引用,各層之間上下界限不在明顯;能夠當作平面的六角形;

2. 六邊形架構(平面)spring

  • 六邊形是平面的架構,其核心是端口和適配器;
  • 將前端和後端的概念延伸爲系統外部區域和系統內部區域
  • 端口處理輸入或處理輸出,適配器將輸入或輸出適配到API中;
  • 端口可提供各類通訊協議,如rest,http,soap,AMQP協議;
  • 適配器用於調用API,且能夠提供各類具體的實現形式;
  • 目前大部分使用spring的架構都是六邊形架構(使用ioc);

3. 面向服務架構 (SOA) service-Oriented architecture,其設計原則以下:json

  • 服務契約 經過契約文檔進行描述
  • 鬆耦合 服務將依賴關係最小化
  • 服務抽象 隱藏內部實現
  • 服務重用性 能夠被其餘服務所重用
  • 服務自治性 服務自行控制環境和資源保持獨立性,
  • 服務無狀態性 服務負責消費方的狀態管理
  • 服務可發現性 客戶能夠經過服務元素就來查找服務
  • 服務組合性 一種服務能夠由其餘服務組合而成
  • 使用soa設計時在於肯定服務的界限上下文,不能爲soa而SOA;
  • 在ddd中,業務價值大於戰術策略,戰略目標大於項目利益;在soa實施中,多考慮業務和戰略 4. rest風格
  • rest Represential State Transfer 表現層狀態轉化
  • 包含http的動做:get,put,post,delete,patch
  • get 獲取資源查詢結果,安全,冪等;可緩存
  • put 覆蓋資源進行更新,非安全,冪等(idempotent)
  • post 新建資源,非安全,非冪等
  • delete 刪除操做,非安全,冪等
  • patch 局部更新,非安全,冪等
  • 數據交換格式大致爲xml或json;通常用json
  • 使用HATEOAS(hymedia as the engine of application service)技術,能夠返回相關資源的連接;
  • 該架構風格具備良好的鬆耦合性和可擴展性

5. CQRS(讀寫分離command-query responsibility sgregation )後端

  • 緊縮(Stringent)對象設計原則和命令-查詢分離(CQRS)原則共同應用的結果
  • 系統中一部分專門負責數據的command命令,另外一部分負責query;
  • 分爲讀模型和命令模型;讀模型能夠新建若干具體的視圖,針對不一樣的需求進行查詢;
  • 命令處理器(Command Processor):處理接受命令.有三種風格:分類風格,專屬風格,消息風格
  • 分類風格(categorized style) 一個服務中不一樣的方法處理不一樣類型的命令
  • 專屬風格(dedicated style) 每一個處理器只有一個單獨的方法,單獨的類處理單獨的命令
  • 消息風格(messaging style) 專屬風格的異步用法
  • 事件訂閱器 用來更新查詢模型
  • 查詢結果是否同步 大部分是作不到同步;有三種方法:1.命令結束,修改緩存數據;2.記錄查詢模型的最新時間,命令操做後自動觸發時間更新,然數據不是最新的能夠發出提醒;3.直接通知數據已被處理,但還須要一段時間才能查看結果; 6. 事件驅動架構(Event-Driven Architecture,EDA)
  • 基於管道和過濾器風格(pipe,filter) 6.1. 基於消息的管道和過濾器處理過程的基本特徵 - 管道是消息通道 - 端口鏈接過濾器和通道 - 過濾器既是處理器 能夠對消息進行處理 - 分離處理器 每一個過濾處理器都是一個分離的組件 - 鬆耦合 每一個過濾處理器都是單獨的參與處理,處理器組合經過配置完成 - 可換性 位置組合科幻 - 過濾器可使用多個管道 並行處理 - 同種類型的過濾器能夠並行運行

-經過消息處理組件訂閱上游的事件,處理以後,發佈自己的事件,下游的消息處理組件將訂閱它; 7. 長時處理過程(Long-Running Process) 7.1. 長時處理過程的設計方法緩存

  • 將處理過程設計成一個組合任務,使用一個執行組件對任務進行跟蹤,對各個步驟和任務完成狀況進行持久化
  • 將處理過程設計爲聚合,這些聚合在一系列的活動中相互協做.一個或多個聚合實例充當執行組件並維護整個處理過程的狀態
  • 設計一個無狀態的處理過程,其中每個處理組件都將對所接受到的信息進行擴充--即向其中加入額外的數據信息--而後將消息發送給下一個處理組件;整個處理過程的狀態包含在每條信息中 7.2. 執行器和跟蹤器
  • 每一個長時處理過程的狀態實例
  • 如何處理系統中消息的重複投遞: 1.查看該事件中的相應的狀態屬性,若是狀態已被設值,執行器會忽略該事件並對該事件做出應答; 2.將狀態對象設置爲冪等,執行後消息不會產生其餘改變.
  • 執行時間校驗;被動校驗和主動校驗;
  • 被動校驗:完成事件到達時執行;經過調用hasTimedOut()方進行判斷;風險:1.事件未完成,未觸發而沒超時;
  • 主動校驗:外部的定時器來校驗.好比JMX的TimerMBean實例,建立一個定時監聽器.缺點,須要更多的系統資源,可能會增長系統的運行負擔;
相關文章
相關標籤/搜索