在做架構設計的時候，一般會採用一些架構模式，便於設計和以後需求變更時修改**。如果設計模式選擇得不正確那麼很容易造成架構的混亂，**也會變成怪物。
分層模式
分層模式是最常見的模式。我們熟悉的mvc模式就是分層模式的一種。在進行架構設計的時候，如果一籌莫展，那麼分層模式是很好的一種嘗試。在分層模式中，業務水平切分，分解到不同的層次中，每個層次要求僅相鄰的兩個層次之間可以進行互動，不可以跨層次進行呼叫。一般架構會被分成3到5層，具體視架構規模而定，大規模的架構可能會超過5層。在分層模式中，可以很好的解耦，不需要跨層次感知下層的存在。這樣帶來的好處就是，如果因為某些原因切換了儲存，這個時候僅需要修改持久化層就好了，再上面的層次完全感知不到底層的變化。
例外情況
但是這種模式中也會存在些例外，底層有的時候需要對上上層進行部分開放。比如新增加了乙個層次，為了適配可能會對一些請求放行，即允許部分跨級呼叫。
分層模式需要注意的時候，層次必須要做處理，如果當前層次僅僅是對請求的轉換，那麼就要考慮是否層次拆分得有問題。如果僅做請求轉換，那麼帶來的僅是效能損失和增加新請求時額外的轉換**。
事件模式1
事件模式2
事件模式有兩種形式：
1.帶有協調器。協調器作為事件總的入口，監聽到事件之後，編排呼叫處理器，使事件按照業務邏輯進行處理和消費，即協調器監聽到事件之後，將事件寫入第乙個處理器，處理器處理完畢後，協調器再將下一步的業務邏輯事件寫到下乙個處理器，由此完成業務邏輯。
2.不帶有協調器，業務流程的處理靠每個處理器走下去。乙個請求到來之後，感興趣的處理器會處理事件，並產生乙個新的事件，並將事件發布到訊息佇列，對新訊息感興趣的處理器再繼續處理新的事件，並再次產生新事件。
這種模式很好的做到了解耦，每個處理器只需要處理自己感興趣的事件即可。但是因為這些事件都是非同步訊息，所以容錯很難處理。
微核心模式
微核心模式也是一種比較常見的模式，比如我們熟悉的eclipse、mysql儲存引擎等。在微核心中，核心的業務邏輯包含在核心中，外掛程式提供對功能的加強。一般情況下，核心邏輯是穩定的，新的需求只需要修改某個外掛程式或者新增外掛程式。外掛程式的邏輯比較專注，只需要關注外掛程式內的邏輯即可。對於核心和外掛程式需要規劃好連線介面。一定要注意，介面要全面，不能僅侷限於當前，不然業務邏輯增加時再增加介面可能會影響到已經存在的外掛程式，使外掛程式不得不進行公升級。
MVC MVP MVVM三種架構模式的區別
一 mvc model view controller mvc是比較直觀的架構模式，使用者操作 view 負責接收使用者的輸入操作 controller 業務邏輯處理 model 資料持久化 view 將結果反饋給view 二 mvp model view presenter mvp是把mvc中的c...
常用架構模式
根據維基百科中的定義 架構模式是乙個通用的 可重用的解決方案，用於在給定上下文中的軟體體系結構中經常出現的問題。架構模式與軟體設計模式類似，但具有更廣泛的範圍。在本文中，將簡要地解釋以下10種常見的體系架構模式，以及它們的用法 優缺點。分層模式 客戶端 伺服器模式 主從裝置模式 管道 過濾器模式 模...
架構之路 MVVM架構模式
model層就是職責資料的儲存 讀取網路資料 運算元據庫資料以及i o，一般會有乙個viewmodel物件來呼叫獲取這一部分的資料。view層做的僅僅和ui相關的工作，我們只在xml activity fragment寫view層的 view層不做和業務相關的事，也就是我們的activity 不寫和...