美麗的架構，是用更少的機制做更多的工作

使用隨意的、非正式的工程技術去開發高效能、高可靠性和高品質的軟體系統會遇到非常多的困難。這些技術對於過去要求較低的系統也許還能對付，而目前 系統的複雜性已經達到了這樣一種程度：如果不開發並維護一個基礎架構，利用它將系統組織成一致的整體並避免零碎的實現，那麼我們就無法應對，必將導致測試 和整合失敗。

但是，建立一個架構是一項複雜的任務。很難得到合適的例子，因為要麼必須考慮專有權，要麼剛好相反，有人需要向各式各樣的環境推銷某一種架構風格。架構是很大的概念，這使得很難在不嚇壞讀者的情況下來記錄或描述。

但是，美麗的架構展示了一些普遍原則，下面我列出了幾點：

一處一個事實

重複導致錯誤，所以應該避免。每個事實應該是單一的、不可分解的單元，每個事實必須獨立於其他事實。當改變發生時（這是不可避免的），只有一個地方 需要修改。資料庫設計者很熟悉這一原則，它以正規化（normalization）之名規範化了。這個原則也不那麼規範地應用於行為，名為提取公因式 （factoring），即同樣的功能提取出來，放到獨立的模組中。

美麗的架構找到了一些方法來定位資訊和行為。在執行時，形成了分層，即系統可以按層來劃分，每個層代表了一層抽象（abstraction）或一個領域（domain）。

自動傳播

一處一個事實聽起來不錯，但出於效率的考慮，某些資料或行為常常會重複。為了維護一致性和正確性，這些事實的傳播必須在構建時自動進行。

美麗的架構是由一些構建工具支援的，結果導致了超程式設計（metaprogramming），將一個事實從一處傳播到多處，在那些地方有效地使用它們。

架構也包含構建

架構不僅包含執行時系統，而且必須包含它的構建方式。只關注執行時程式碼會導致架構隨時間的推移而退化。

美麗的架構是經過深思熟慮的。它們不僅在執行時是美麗的，在構建時也是美麗的；利用同樣的資料、函式和技術來構建系統，就像在執行時使用的那樣。

最少量機制

實現某個功能的最佳方式要視情況而定，但是美麗的架構不會追求“最佳”。例如，有許多種方式可以儲存和查詢資料，但如果系統利用一種機制達到了效能要求，就會考慮編寫、驗證和維護較少的程式碼，以及佔用較少的記憶體。

美麗的架構使用一組最少的機制來滿足整體的需求。找到每種情況下的“最佳”，會導致各種容易出錯的機制的產生，而用極簡的方式來新增機制則會得到更小的、更快的、更健壯的系統。

構建引擎

如果您希望構建脆弱的系統，就採用Ivar Jacobson的建議，將架構建立在用例的基礎上，每次實現一個功能（例如，使用“控制器”物件）。但是，可擴充套件的系統依賴於虛擬機器的構建，即由更高層提供的資料來“程式設計”的引擎，一次實現多個應用功能。

這個原則以多種外觀出現。虛擬機器的“分層”可以追溯到Edsger Dijkstra。“資料驅動的系統”提供了引擎，依賴於系統中的編碼常量，讓資料來定義特定情況下的具體功能。這些引擎是高度可複用的，也是美麗的。

O(G)，增長的階

在以前，我們會考慮演算法的“階”，例如，根據對一組一定數量的元素進行排序的時間來分析排序的效能。許多書籍都是圍繞這個主題來寫的。

這同樣適用於架構。例如，一個投票程式在少量資料的情況下工作得很好，但資料量增大時響應時間就變得難以接受。按照中斷或事件來組織所有的工作，在開始時會工作得很好，但後來可能突然出現問題。美麗的架構會考慮可能的增長方向，並能夠支援這種增長。

抵制熵增

美麗的架構設計了一條最容易維護的路線，隨著時間的推移仍能夠保持架構，所以延緩了“系統熵增定律”的效果。該定律指出，系統會隨著時間的推移變得越來越亂。維護者必須適應該架構，這樣變更才能與架構保持一致，不增加系統的熵。

一種方法是利用敏捷開發的隱喻（Metaphor）概念，它是一種簡單的方式，說明架構像什麼。另一種方法是使用大量的文件，並以解僱相威脅，雖然這種方法難以取得長久的效果。然而，這通常與工具有關係，特別是那些生成系統的工具。美麗的架構必須保持美麗。

這些原則是高度相關的。只有在你實現了自動傳播時，一處一個事實才行得通，而自動傳播又只有在架構考慮到構建時才有效果。類似地，構建引擎和最少量 機制支援一處一個事實。抵制熵增是長時間保持架構的要求，它靠的是架構包含構建方法並支援自動傳播。而且，如果忘記考慮系統將以何種方式增長，將導致架構 不穩定，最終會在極端但可預見的環境下失敗。將最少量機制與構建引擎的觀點結合起來，就意味著美麗的架構通常包含一組有限的模式，同時支援構建任意的系統 擴充套件，這相當於“按模式擴充套件”。

簡而言之，美麗的架構用更少的機制做更多的工作。

《架構之美》（Beautiful Architecture）由Diomidis Spinellis和Georgios Gousios彙編而成，當你閱讀本書時，你可以透過每章提供的具體例子，尋找這些原則並思考它們的意義。你也可以尋找違反這些原則的情況，想想這是否導致架構變得醜陋，或涉及某些更高的原則。

在寫這篇序時，作者問我能否說說如何才能成為好的架構師。我笑了起來。如果我知道的話……但是接著我從自己的經歷中想到，有一種特效方法（注）可以 幫助人們成為美麗的架構師。這種方法就是永遠不要相信你最近建立的系統是唯一的，應設法尋找不同方法來解決相同型別的問題。本書提供的美麗架構的示例就能 幫助你朝著實現這個目標邁出一步。