架構設計兩大支柱思維：
能夠通過分解或者分層進行應用簡化
首先分析應用的功能需求
然後決定如何對應用進行分解或者分層
也就是說這個策略會幫助我們將應用如何合理分層，以及每一層應該處理的功能。
要能夠讓分層的邏輯簡單直接
換句話說，不能因為分層反而造成應用變得複雜
一般對於乙個網路應用程式，大致包含如下功能：
處理使用者的輸入內容，然後返回給使用者需要的內容
需要對程式中出現的錯誤返回給使用者合理的問題描述
事務處理
進行使用者的授權和認證
實現應用程式的業務處理
和資料儲存系統以及外部系統進行互動
我們把程式的功能實現分為三層進行處理：
web 層，網路應用程式的最外層，負責處理使用者的輸入然後返回使用者需要的內容；web層要負責異常處理的資訊展示；web層是程式的入口，它要作為第一道防線，來對使用者進行認證和授權。
service層，它位於web層之下，執行乙個事務邏輯完整處理，通常包括應用服務和基礎服務。應用服務提供了service層的公共介面，作為事務的完整處理，它也負責授權認證。基礎服務負責和外部資源，比如檔案系統，資料庫系統，郵件伺服器，進行資料傳輸。通常這些服務被多個應用服務所使用。
repository層，網路應用程式的最底層，它負責和資料儲存器打交道，增刪改，查詢等等。
下面要理清層與層之間如何互動，也就是介面如何定義。我們會用到兩個術語：dto資料傳輸物件和domain model業務模型物件。
dto比較好理解，就是資料的承載物件，負責在層與層中間的資料傳遞，而業務模型則包含了三種型別：
無狀態業務服務物件，提供與業務概念相關但又不屬於乙個實體或者值物件的一些操作；
實體物件對應於能夠在整個生命週期都保持乙個唯一標識的物件；
值物件描述乙個屬性，它沒有唯一標識，它的生命週期只能與乙個實體物件繫結。
這裡會對dto產生疑問，為什麼不能直接傳遞給web層實體物件或者值物件？
如果傳遞實體物件到web層，那麼web層就必須了解如何使用它們，web層承擔了它職責以外的事情；相反如果僅傳遞dto,web層的**看起來會更加簡潔清晰。
如果暴露細節給web層，對於業務模型的修改就會受到牽制；如果僅傳遞dto,那麼只要保持dto不變，業務模型可以根據需要進行各種程度的更改。
根據以上分析，我們得出最終的架構設計：
以上翻譯自：
mysql經典應用架構 MySQL經典架構
mysql主從複製 此種架構，一般初創企業比較常用，也便於後面步步的擴充套件 此架構特點 1 成本低，佈署快速 方便 2 讀寫分離 3 還能通過及時增加從庫來減少讀庫壓力 4 主庫單點故障 5 資料一致性問題 同步延遲造成 mysql mmm架構 通過 drbd 基於 block 塊的複製模式，快速...
springMVC架構搭建
1依賴jar包 2.springmvc的配置檔案web.xml 在web當中配置 disparcherservlet,用來啟動 springmvc 攔截請求，把需要有 controller 處理的請求交給 controller.x servlet.xml 預設的名字，對應 web.xml 當中配置 ...
springmvc核心架構
3 dispatcherservlet handleradapter，handleradapter將會把處理器包裝為介面卡，從而支援多種型別的處理器，即介面卡設計模式的應用，從而很容易支援很多態別的處理器 4 handleradapter 處理器功能處理方法的呼叫，handleradapter將會根...