第五部分 軟件架構
什麼是軟件架構？軟件架構工作本質上是在回答一個關於“如何將系統切分成組件，並且處理好各組件之間的關係”的問題。一個優秀的架構師應該允許系統儘可能推遲與實現細節相關的決策。要設計一個好的軟件架構，除了要使系統用例的正常運行，還要同時考慮系統的維護、開發以及部署等非需求因素。
那麼爲了儘可能地將一些與系統核心業務邏輯無關的決策延後，我們就必須劃分好軟件架構中的清晰邊界。比如業務邏輯和數據庫之間就應該有一條邊界線，因爲你是具體使用Oracle還是MySQL作爲數據庫，都不應該影響核心業務邏輯。同理，用戶界面也與業務邏輯無關，所以這兩者之間也應該有一條清晰的邊界線。因爲具體使用的是命令行界面還是使用網頁等UI方式來呈現，本質上都與核心業務不是緊密相關的。在具體的架構實踐當中，有一種叫做插件式架構的方式廣爲流傳，其理念就是將核心業務邏輯和其他組件（作爲外部插件）進行隔離開來。
一旦邊界劃分完畢之後我們就得進一步思考如何處理跨邊界的調用，最簡單的跨邊界調用方式就是用低層客戶端來直接調用高層服務函數，這在單體架構當中十分普遍。我們這裏所說的高層和低層組件，其實是按照輸入與輸出之間的距離來進行定義的，通常來說它距離系統的輸入或者輸出越遠，它所處的層次就越高，而能夠直接管理輸入輸出的策略，在系統當中就是屬於低層的。拿操作系統來舉例，低層的組件就是那些管理磁盤的程序，而高層的組件就是依賴磁盤管理程序的文件管理系統。由於低層的組件通常來說比較容易頻繁變更，而高層組件相對來說較爲穩定，因此我們需要將低層組件隔離開來，並且將依賴關係都統一調整爲指向高層策略。低層次組件要跨越邊界到達高層組件，這個數據流是自下而上的。所以一旦我們需要使高層組件能夠調用低層組件，就需要運用動態技術來反轉依賴關係，比如使用動態鏈接庫。對於我們常見的Main組件應該是整個系統中的一個底層組件，它處於整潔架構的最外圈，負責加載系統信息，然後將控制權轉回到系統的高層組件。
要實現跨越邊界的調用，除了直接的函數調用外，我們還可以引入線程，進程以及服務的方式。
我們在軟件架構當中還經常提到的一個概念是業務邏輯，那麼對於一個軟件來說，其最核心的業務邏輯是什麼呢？它本質上就是系統軟件系統中那些能夠真正產生商業價值的邏輯和過程，無論它是否是以計算機軟件的方式進行實現的，它的作用和邏輯都應該是相同的。因此我們通常會將這些關鍵的業務邏輯出現成一個業務實體，並且作爲高層組件，至於底層的具體實現則交由低層組件來完成。
在很多設計不佳的軟件裏，你經常會看到業務邏輯和數據庫以及用戶界面等邏輯相耦合，這樣隨着時間的推移，軟件的可維護性和代碼質量都很難得到保障。
一個系統的架構應該着重於對於系統，用例本身的設計，而應該儘量避免強依賴於系統所使用的框架。
跨越邊界的數據，應該保持數據結構的簡單，而且不應該違反依賴規則。
在系統架構的邊界處，可以使用謙卑對象模式，這種模式可以很好的提高系統的可測試性。一個很好的例子就是對於GUI的實現，我們可以將其分爲展示器和系統視圖兩個部分。其中視圖部分屬於謙卑對象，該對象只負責將數據填充到 GUI上。而另一部分是展示器對象，它負責從應用程序中接收數據，然後按照視圖的要求將這些數據格式化。謙卑對象同樣也可適用於數據庫網關、數據映射器ORM等場景中。
我們通常會認爲服務是解耦合的，但是一旦服務之間使用了共享數據，它們就會形成強耦合關係。按功能劃分服務的架構方式，在跨系統功能變更時是比較脆弱的。那麼對於這些橫跨系統之間的變更，我們應該如何處理呢？如果運用面向對象方法，可以採用模板方法模式或策略模式來將原先服務化設計中的大部分邏輯包含在基類中，然後針對特定的邏輯可以抽離到一個單獨的組件當中去。要是使用基於服務的方式，則可以用衍生類，爲原有的服務添加新功能。
第六部分 實現細節。
這部分主要通過一個視頻銷售網站的案例分析，來闡述組建架構以及依賴關係管理等，處理的思考過程。
我們需要注意的是，無論是數據庫、WEB UI還是應用程序框架，這些都是實現細節，不應該成爲架構設計的阻礙。同時無論我們採用水平拆分的架構（按層拆分）還是採用垂直拆分的架構（按功能拆分），都需要將設計映射到對應的代碼結構當中去。最好能夠使用編譯器來維護所選的系統架構設計風格，這些細節都很關鍵。