一、什麼是架構
在牛津高階詞典（第7版）中，架構（architecture）一詞的解釋是：the design an structure of a computer system，而架構師（architect）一詞的解釋是：a person who is responsible for planning or creating an idea， an event or a situation.
針對於企業應用，依據不同的關注點，架構可以分為如下幾類：
業務架構（Business Architecture）：關注於業務及其流程；
應用架構（Application Architecture）：關注於應用系統設計；
基礎架構（Infrastructure Architecture）：關注於基礎技術；
數據架構（Data Architecture）：關注於數據存儲及其規劃；
這裡所說的企業應用架構，即屬於應用架構，包括如下幾個部分：
1.目標和願景。即應用系統所面臨的問題域。
2.評價指標。從哪些緯度和指標來評價和度量解決方案。
3.原則和方法論。為解決這些問題，所采用的原則及其方法論。
4.技術架構。架構的技術層面，給出相應的設計以及結構，描述應用系統。
5.組織因素。架構的組織層面，組織的各個部分如何參與。
二、架構的目標和願景
1. 架構的問題來源
1. 外部，客戶要求包括了業務和技術上。
2. 內部，組織管理、項目管理和技術發展上。
特別的，架構需要解決的非業務問題包括如下：
A.系統目標：系統性能，穩定性等。
B.項目目標：開發成本，項目質量等
C.項目過程：需求的不確定性和開發過程的團隊協作性，即所謂的開發管理。
2. 架構的核心問題
問題可分解為兩種類型，業務上和技術上。
1. 業務上。問題域分解為，邏輯的縱向抽象層次，以及邏輯的橫向模塊分解和集成。
2. 技術上。問題域分解為，縱向的技術主題，以及橫向的技術職責的分解和集成。
A.領域化
傳統的架構模式是三層或者四層模式，雖然從技術上有效的橫向分解系統結構，但對業務模型如何建立，如何進行層次間傳遞，模型間關聯關系，以及與服務邏輯耦合等問題沒有給出進一步的細化，也帶來了很多問題。
此外，在傳統設計方法下，分析模型和設計模型的轉換也是一個大的問題。
B.組件化
實施組件化或者說模塊化，其需求分為兩個層面。
1.內部管理，可以幫助開發過程中進行業務切分，幫助控制進度，降低風險，以及財務分析；對於大型復雜的項目，也有利於知識的傳遞和積累。
2.銷售需要，All in one的系統因不符合發展趨勢而不利於銷售；組件化有助於產品銷售，可以針對客戶，將若干組件打包銷售，同時減少集成的風險。
C.產品化
C.1 定制化問題
定制化問題的由來：1.面向行業的應用通常沒有標准，或者完備的標准；2.通常產品的開發是針對於通用或者公共需求，不針對於特定客戶；3.而一個確定的客戶，其自身的業務差異和管理差異導致需求的差異性。
這種現象尤其在缺乏標准的行業應用中，以及系統的產品化過程中。
傳統的簡單的解決方式是為每個客戶單獨維護一個系統分支，在此情況下提供維護和升級，則維護成本巨大；因此如何解決領域的定制化就成為一個重大問題。
C.2 升級問題
領域需求每次進一步的挖掘和實現，都意味著領域的升級。但升級面臨的諸多問題：數據遷移，舊版本的兼容問題，依賴關聯等等，在組件化和定制化情況下，還面臨定制化兼容和沖突檢測。
C.3 國際化問題
1.文本消息國際化
國際化消息沒有直接呈現，而是中間存儲後呈現；
2.布局國際化
阿拉伯人是從右到左；
3.業務時間，跨時區；
4.計量單位，多幣種；
D.平台化
應用系統可以分為兩個內容：應用程序和基礎設施。應用程序處理業務問題，而基礎設施處理技術問題。
來自客戶的要求是包含業務和技術兩個方面。其中技術上包括兩種“定型和定性”，其所需的知識和技能是不同於業務上的；
此外，內部管理也提出相應的要求。由於技術的發展和業務發展之間的不同步，對於一個產品而言，同時存在技術升級和業務升級兩個需求。而同時升級存在較大的成本和風險。
同時對於一個產品來說，技術方面需要較強的適應性，能夠低成本上的適應客戶的特別要求。
因此有效解藕技術和業務兩個部分成為必然。
3. 架構的應用問題
A.事務管理
數據一致性問題出現的原因通常是開發過程中，由於錯誤的並發和事務控制導致的；而在業務過程中也存在錯誤的業務操作情況。
B.並發處理
不同的業務應用存在不同的並發場景（並發度以及存在的業務依賴），因此業務上需要明確原則和方案；而不同平台所支持的並發方式和能力也不相同，則采用一定框架支持有助於簡化問題。
C.集成能力
業務應用所面臨的集成問題不同，包括不同的集成環境：外部系統，內部系統，遺留系統等；不同的集成模式：基於文件，基於數據庫表，基於消息等，導致所需的集成方法及其能力也不同。
4. 架構的設計問題
分析設計和開發實現存在著一定的差異性：分析設計屬於知識級，而開發實現屬於操作級的。
分析設計是需求和實現的中間橋梁，因而設計必須解決系統邊界的合法性，內部邏輯解藕的合理性和實現的可達性（設計的類方法為實現的30%-70%）。而開發實現需不斷重構代碼，采用約定和框架能力等技術手段解決開發的實際問題，解決程序級別的健壯性，可讀性，可維護性以及可測試性。
傳統的方式，分析設計存在於文檔中，而開發實現存在於代碼中。兩者的割裂導致溝通的困難，也導致了開發工程中具大的風險——分析設計和最終開發實現的不一致性。
三、架構的評價指標
1. 財務角度
在傳統的財務核算機制中，系統或者產品的開發通常屬於成本中心，對於IT企業來說，電腦設備，辦公室等屬於沉沒成本，而IT人員的工資屬於可變成本，是成本的核心部分，為了控制成本，就需要減少項目的開發時間。
因此架構一個重要的關注點在於控制開發成本和維護成本，通常講維護成本是開發成本的3倍。降低開發成本核心，在於提高效率、提高適應需求變化的能力。
2. 技術角度
技術角度評估架構很難說一個架構行或者不行。技術角度需要給出的最大指標是風險性。而風險性和各個指標因數有很大相關，但還需要結合相應實際情況判斷。例如：如果決定了不可能換數據庫，那麼即便強綁定Oracle也沒有特別的風險。
以下指標參考了架構的質量特性，但進行了裁減。
A.內部指標
1.侵入性。或者說是可遷移性，即系統與外部資源的關聯關系，以及系統內部的關聯關系。例如，如果架構決定使用pl/sql，那麼就意味著架構和Oracle數據庫是強綁定。
2.重復性。雖然我們都知道關於重復的兩個原則（1.不要重復，2.不要自己重復），但是有時重復看上去無法避免，那麼就是判斷這個重復性帶來的問題有多大。
3.擴展性。即架構提供何種條件下的何種擴展和變化能力，及其成本。
4.平穩性。在業務或技術擴展時的，架構所呈現的發展態性。
5.抽象性。即可視性，並包括了概念完整性。系統是否完整以及層次化的反映應用問題，能否明確的呈現和表達。
6.修改性。包括了可重構性，代碼級別的侵入性以及單元測試能力。
7.診斷性。系統提供的實時觀測能力。
B.外部指標
1.性能。
2.可靠度。
3.可用度。
3. 組織角度
組織角度涉及兩個方面：人和流程。
人的方面，架構需要組織的角色參與（業務專家，技術專家）及其參與度，以及涉及到人力資源匹配情況。若架構所需的技術如果太新或者太窄，將面臨人力資源的困境。
流程上，要看架構是否與流程匹配。架構原則指導下不同角色在不同階段關注點不同，而工程實踐中，不同流程階段需要提交的產出物也不同，此時就可能存在二者不匹配的情況。
四、架構的原則和方法論
1. 原則
總原則是：關注點隔離。
在解決各類問題都應以此原則為指導。但針對於不同層面該原則的變化不同。針對於高層設計（概要設計）：合理劃分邏輯邊界；針對於詳細設計層面是：任何改動最多涉及一個接口和一個實現類（簡單類職責的變體）。
2. 方法論
方法論有兩個：自上而下，由內而外。
其對應的完整理論體系為：面向對象/面向方面，領域驅動設計以及測試驅動設計。
3. 發展與演化
A.總結歸納型
這個方式最常見。程序員所需要面對的問題是：在有限的時間、資源，面對有限的需求，在容錯范圍內的做出一定的產品。在這種有限條件下反復訓練出來的決策機制，使得程序員對歸納法有著特殊的偏好。它對於程序員開發的大部分工作都是行之有效的。
B. 技術思辨型
通過更廣泛的分析，獲取深刻的理解和普遍的關聯，以創造新穎的技術。所謂大牛們正是如此。例如GC算法，例如AOP技術。
