換句話說，也就是想要構建一個通用的，適應性較強的架構

其實說來說去，一般開發仍然是從三層架構為基礎進行迭代升級。無非也就是表現層業務層持久層。如果想要更“自有”一點，我們可以把閘道器層作為最上層（controller只是其中一部分），中間自然還是業務層，當是我們平時的service只是業務層的入口，最下層自然是基礎層，dao也只是他的元件之一。

這個閘道器層本質也就是對協議的處理。HTTP請求，TCP請求等。

業務層可以大致分為三個部分

業務服務（對外的門面，介面，出參，入參）

業務流程，最容易變化的就是這裡...

業務元件，其實也就是一些內聚可複用程式碼片段進行封裝，各元件功能不同，本質還是一樣的

無非也就是那幾個，資料儲存，快取，訊息。需要關注的無非也就是事務。

首先，業務的理解是必不可少的，你不可能脫離業務去空想一個架構，這個是不切實際的：

前期的業務溝通我都是會參加的，並且我參與的系統大多數都是老系統的重構，所以老系統是什麼樣子，都需要進行了解。

業務的需求究竟是一個什麼樣子的，需要深度挖掘，避免遇到假需求。

和周邊系統有哪些互動，這個是必須瞭解的。

老系統有哪些缺陷，是需要在新系統避免的。

對新系統的業務壓力和資料量，需要有一個評估。

在設計的過程中，技術知識的儲備很重要，你需要了解每項技術的優缺點和適用場景，常見問題的解決方案。

首先說說什麼是“假需求”，比如一個人管你接紙巾（需求），你沒有（無法滿足需求），你是直接說“我沒有”還是說“你要紙巾做什麼（挖掘客戶真實需求）”。對方說“我要紙巾擦桌子（真實需求）”。你正好有抹布，不就滿足對方真實的需求了麼。挖掘出使用者真實的需求之後，才能避免一些無用的機構設計。

和周邊系統互動問題，這個也很關鍵：如果有系統會請求你的服務，並且對方系統是24小時執行的，那麼你必須考慮叢集部署+灰度釋出了；如果你和另外一個系統的交易實時性要求不是那麼的高但是請求很頻繁，那麼就可以考慮引入訊息中介軟體。

老系統的缺陷，是一定要避免再次入坑的。比如老系統某些功能在效率上很差，那麼在新系統的設計中，是不是就可以考慮引入記憶體資料庫。

業務壓力的評估，是必不可少的。如果併發量比較高，那麼需要多少資源實現都要評估出來，並且叢集+負載均衡。如果資料量很大的話，是不是考慮讀寫分離，甚至分庫分表。

架構設計包括系統功能結構設計、系統技術架構設計（所用技術及分層）、資料架構設計、系統部署方案、網路部署方案等等。

系統技術架構設計：

資料架構設計：