6.1 分解
儘管標準多種多樣，但大型系統開發的主要任務是降低系統的複雜性。為了降低複雜性，除了分成幾部分之外什麼也沒有發明。
有時，為了簡單起見，這被稱為“分而治之”原則，但是，從軟件架構師的角度來看，我們談論的是層次分解。
一個複雜的系統必須由少量較簡單的子系統構建而成，每個子系統又由較小的部分構建，依此類推，直到最小的部分足夠簡單，可以直接理解和創建。
好消息是這個解決方案不僅是唯一已知的，而且是通用的。除了降低複雜性之外，它還通過複製關鍵部分同時提供系統靈活性、良好的可擴展性和增強的彈性。
因此，當談到構建程序的體系結構、創建其結構時，這意味著將程序分解為子系統、服務、層、子例程和功能模塊，並組織它們之間以及與外部世界的交互。
這裡最有價值的是：子系統越獨立，在特定時間點專注於每個子系統的開發而不用擔心所有其他部分就越安全。
6.2 模塊化架構的好處
使用層次分解原則可以讓你擺脫代碼中數千個類的混亂。還記得你的代碼被分成包（package）和子包嗎？這是層次分解的一種表達方式。
你的程序從一堆類變成一組庫和模塊，它們根據明確定義的簡單規則相互交互。反過來，這使您能夠控制其複雜性，並讓您有機會獲得通常與良好架構概念相關的所有好處。
以下是最基本的：
- 可擴展性——通過添加新模塊擴展系統並提高其性能的能力。
- 可維護性——改變一個模塊不需要改變其他模塊。
- 模塊的可交換性（Swappability）——模塊可以很容易地被另一個替換。
- 單元測試——一個單元可以與所有其他單元分離並進行測試/修復。
- 可重用性——模塊可以在其他程序和其他環境中重用。
- 維護——一個被分成模塊的程序更容易理解和維護。
可以說，將一個複雜的問題分解成簡單的碎片是所有設計技術的目標。在大多數情況下，術語“架構”只是指這種劃分的結果加上“一些一旦採用就難以更改的設計決策”（Martin Fowler“企業軟件應用程序架構”）。
因此，大多數以一種或另一種形式的定義歸結為以下內容：
“架構確定了系統的主要組件以及它們如何交互。它也是對此類決策的選擇，這些決策被解釋為基本的並且在未來不會發生變化。”
“架構是一個系統的組織，體現在它的組件中，它們之間的關係以及它們與環境的關係。系統是一組組合起來執行特定功能的組件。”
因此，好的架構首先是模塊化/塊式架構。要獲得良好的架構，您需要知道如何正確分解系統。這意味著有必要了解哪種分解被認為是“正確的”，以及如何最好地進行分解。