現代企業架構框架-應用架構
現代企業架構框架： //mp.weixin.qq.com/s/SlrEu0_t0slijrNZ6DP4Ng
業務架構： //mp.weixin.qq.com/s/zQCjiHuxFvAg5QiOAuLAcQ
4.應用架構
應用架構的核心關注點是業務需求是由哪些應用承載的，它們與用戶是如何交互的，它們之間的關係以及是如何交互的，它們訪問或變更了什麼數據。
應用架構的設計主要以應用（Application）的設計為核心，向外圍可以延伸到平台型企業架構對於應用分層，分組的設計。例如大家關注的以微服務為代表的分散式應用架構，以及此類架構模式下的常見問題，例如微服務如何劃分如何組織，都是應用架構在這個粒度需要關注的問題。
同樣，以應用為基準，向內部延伸又會涉及到應用內部的架構設計。例如常見的應用分層設計，領域驅動設計中提到的六邊形架構、洋蔥模型，包括領域對象的詳細建模與設計，都是在應用架構這個粒度需要關注的問題。
而其中的領域對象設計在業務架構以及後續的數據架構中都會提及，本框架充分融合了企業架構與領域驅動設計的思想和方法，從業務架構到應用架構以及後續展開的數據架構，都秉承以領域對象設計作為架構的核心要素，跨越架構邊界，使領域對象作為一條主線，串聯起各個架構視圖，也有利於保證各類架構的連貫和一致性。
4.1應用架構元模型綜述
應用架構的內容元模型包括「埠」、「結構」、「狀態」三個部分，如下圖所示：
- 結構部分用來對 IT系統的職責、邊界建模，其中包括，應用組件、應用、應用組、應用層
- 埠部分用來對應用的出入口建模，其中包括應用服務和擴展點
- 狀態部分用來對應用狀態的變更建模，其中包括領域對象和不變數
4.2 應用架構元模型應用
4.2.1 平台化趨勢對應用架構提出的新挑戰
平台化趨勢意味著企業 IT 系統的形態逐漸從扁平結構轉向分層結構，即一部分應用提供可復用的能力， 組成底部的平台，而其他應用建立在平台之上。除了能力復用外，另一個提升 IT 支撐響應力的關鍵是，提升 IT 系統各組成部分的自治性，使得變更能夠相對獨立的、以小步快跑的方式發生。因為無論是創新也好，集中管控也好，雖然變化速率不同，但變化始終存在，既然變化不可避免，我們應將精力投入到應對變化上。
在我們的經驗中，應用邊界劃分不合理會對應對變化產生明顯的負面作用：
這些負面作用會拖慢 IT 支撐的響應力或穩定性，因此，「如何劃分 IT 系統的邊界，以合理的布局更好地應對變化」是需要解決的挑戰。在平台化趨勢之前就已經開始流行的微服務架構風格的催化下，這個挑戰就已凸顯，而平台化強調可復用的服務，必然會對原有系統進行打散和重組，進一步加劇了這個挑戰。
4.2.2 如何劃分 IT系統的邊界，以合理的布局更好地應對變化
從上文的分析可以看出，邊界劃分其實從應用架構視角出發，對功能、運行層面變化的應對設計，是應用架構設計的重要部分。我們在進行應用架構設計的過程中，融合了領域驅動設計中的限界上下文與統一語言的概念，延續業務架構部分中對於領域對象的識別和子域劃分，結合組織與技術的要素， 從多個方面充分考量對於應用的建模。
限界上下文（Boundary Context）：是業務上下文的邊界，在該邊界內，當我們去交流某個業務概念時，不會產生理解和認知上的歧義（二義性），限界上下文是統一語言的重要保證。
統 一 語 言 （Ubiquitous Language）： 是 Eric Evans 在《域驅動設計 – 處理軟體核心中的複雜性》中使用的術語，用於構建由團隊，開發人員，領域專家和其他參與者共享的語言，也稱為無處不在的語言、通用語言、泛在語言。統一語言是在限界上下文中建模的，在其中標識表達了業務領域的術語和概念， 並且不應該有歧義。
帶著對於業務上下文邊界的理解，使用業務、技術都能理解的統一語言，以兩大階段實現邊界劃分：
- 從功能需求層面出發，按「單一職責」原則劃分邏輯邊界
- 加入非功能需求，按架構品質屬性調整邏輯邊界並劃分物理邊界
這個設計過程可通過元模型提供的應用層、應用組、應用、應用組件進行不同層次的邊界劃分建模。
4.2.2.1 應用組建模
應用組是一種大比例結構的邏輯邊界劃分結構，其主要作用是：
- 應用組作為一種粗粒度的劃分，幫助我們快速找到進一步劃分的切入點
- 在微服務化的大背景下，物理邊界逐步碎片化， 我們在與利益干係人對話時，需要一個能夠代表一組相關物理邊界的結構，以避免不必要的細節干擾
在結構上，應用組包含了多個應用（物理邊界）。應用組常常對應到數字化產品級別，例如 CRM 系統（客戶關係管理系統，其下可能包括客戶檔案管理應用、客戶忠誠度管理應用）；在業界流行的按中心劃分的中台 / 平台架構里，應用組常常對應到某個中心。
應用組的建模依據主要來自於業務架構的業務、組織兩部分成果的輸入。在從 0 到 1 的應用架構設計場景里，這個步驟不求精確，主要是幫助我們建立劃分的起點。例如：
汽車行業的經銷商，會同時開展新車銷售和售後服務兩個不同的業務，在經銷商內部一般也由不同的組織負責。
而維修保養和配件銷售又是售後服務中的兩個不同業務場景。
我們可依此快速建立一個兩級的應用組， 這個結構並不精確，但足夠我們進行下一步工作。
4.2.2.2 應用組件建模
應用組件是一種細粒度的應用邏輯邊界劃分結構， 是對功能、數據的封裝。
向上，一個或多個應用組件可組成一個應用（物理邊界），向下，就是程式碼實現層面的結構設計了。因此，應用組件是架構層面運用「單一職責」原則的最小單元。
按職責類型分解，應用組件可分為四種常見的參考類型
一般來說，我們建議從流轉類的應用組件開始識別， 再延伸至規格類、視圖類，最後再識別配置類。建模依據主要來自於業務架構的業務流程、業務對象、業務規則。其過程可總結為三個子步驟：
子步驟一：功能和數據識別
逐層分解業務流程，從活動、任務、步驟中可以得到相對細粒度的業務需求，即 IT 系統需要提供的功能；將業務對象轉化為不同類型的數據對象。
子步驟二：功能與數據關聯，識別應用組件
按不同組件類型將功能與數據對象關聯對應，得出應用組件。在流轉類組件建模時，有兩個關注點需要特別注意：
一是隱式業務邊界的識別。在對業務流程分析時， 地點、角色變化時，我們面對的業務干係人和他們的工作環境不同，其關注點可能不同，這往往會成為不同的變化原因。通過識別這類隱式的業務邊界， 這可以幫助我們細分數據對象和應用組件，例如：
線上訂餐流程中，客戶提交訂單並完成付款後，訂單會被派單至廚房備餐。即使在業務架構的產出中沒有識別出客戶訂單和廚房備餐單據可能是不同的業務對象，也可以從地點和角色的變化將訂餐結賬、備餐識別為不同的應用組件
二是數據對象變更一致性約束的識別。在流轉類應用組件的建模過程中，應該儘可能識別業務規則中對於數據對象變更的一致性約束，以元模型中的「不變數」建模。不變數代表了哪些數據對象需要被同時改變，我們可以依此複查，是否將應用組件拆分得太細，破壞了事務邊界。
子步驟三：識別、調整各應用組件之間的依賴關係
識別各組件間的依賴關係，在這裡儘可能避免兩種依賴：
一是儘可能避免依賴容易變化的組件。儘管可以定義契約，但容易變化的組件容易打破先前定義的契約。
二是儘可能避免出現雙向依賴。雙向依賴往往對可適配性產生負面影響，可通過引入第三個組件或擴展點（詳見「應用服務與擴展點」）解耦：
4.2.2.3 應用建模
有了應用組件作為「原料」，應用架構的物理邊界設計就有了輸入，下一步的目標是識別是否存在架構品質屬性衝突，作為應用建模的重要參考，調整邏輯邊界，並確定物理邊界。品質屬性衝突包括：
• 該邊界內是否存在變更頻率衝突
我們傾向於將高頻變更的應用組件與其他應用組件阻隔開。物理邊界意味著部署的獨立性，不容易產生髮布計劃、部署所需資源上的衝突。如果一個功能擴展帶來的變更，集中在某個應用、甚至應用組件內，其協作成本相對更低。
• 該邊界內是否有特別的移植性要求
該要求指應用遷移到不同組織、業務運作方式的能力，或者換一個角度來說是應用承接新業務模式的能力，這恰巧是平台所需要的關鍵能力。在實現某一個業務模式時，必然存在該業務模式的特定需求和可以支援多個業務模式的公共需求。我們傾向於將特定需求和公共需求的實現隔離到不同的應用組件、甚至應用里。以便新業務模式入住時，方便實現功能擴展以及實現部署要求。
• 該邊界內是否有特別的彈性要求
該要求指應用是否容易通過調整容量來應對流量變化。在這裡應用的粒度決定了容量調整的難度和成本。因為應用的粒度太大，而流量變化隻影響其中某個應用組件，則擴容帶來了不必要的成本浪費。另一種情況是某個應用組件不能調整容量或者非常困難，這主要是因為其依賴於某個無法擴展的技術組件。例如，某應用組件依賴硬體加密設備（技術組件）對報文進行加密，擴容意味著需要採買硬體加密設備。因此，需要將這類應用組件隔離開，使其他組件更容易應對彈性要求。
• 該邊界內是否有特別的性能要求
該要求與彈性要求類似，將不同性能要求（請求處理的快慢程度）的應用組件分開，特別是對於特定問題，可能適合某個技術棧，但出於整體建設、運維成本考慮並適合大面積使用，我們傾向於將其設計為一個獨立的應用，與其他應用組件隔離開，使得異構。典型的例子是，部分高性能場景適合用 C 語言實現。
• 該邊界內是否有特別的可用性要求
該要求與彈性要求類似，將不同可用性要求的應用組件分開，降低保障可用性要求的建設、運維成本。例如，如果某個應用組件支撐的功能尚處在業務探索階段，那麼可以適當降低其可用性要求，這要求將其與承擔核心功能的應用組件隔開。或是當故障發生時，能否將故障隔離在局部範圍，減少應用失效造成的業務損失。
• 該邊界內是否有特別的資訊安全要求
例如，某應用組件需要保管信用卡持卡人資訊，為降低該資訊被非授權訪問的風險，我們傾向於將該應用組件與其他應用組件拆開，將其獨立部署在一個加固的運行環境中。
• 該邊界內是否有特別的合規要求
有時邊界劃分會受到法律、法規或行業規定的影響。例如某業務是需要公證的抽獎活動，按照當地行業要求，中獎人抽取的實現需要通過xxx認證。我們傾向於由已通過認證的外部應用服務來提供該職責，或是將該職責獨立劃分為一個應用，減少認證需要花費的時間。
基於以上衝突的進行邏輯邊界調整，將由特別要求的應用組件獨立劃分到各自的物理邊界，剩餘的應用組件原則上保留在一個物理邊界，以元模型中的「應用」表述該劃分結果。
4.2.2.4 應用層建模
除了應用組之外，常見的一種大比例結構是分層， 因此我們也將應用層作為一種元素加入進來。我們認為分層代表了企業對變化速率的認知，並為不同的變化速率匹配架構設計目標和管理方法。並不是所有的 IT 系統都需要「最高配」的架構屬性，實現成本也是重要的約束條件。一個處在業務探索期的資訊體統，其生命周期一般只有 6-12 個月，且變化劇烈。為其達成過高的架構屬性顯然是不具備投資合理性的。
另一方面，平台化架構中作為支撐層的 IT 系統在架構屬性上需要更多重視和投入。我們常常看到企業僅僅在全景圖紙上做了分層，但缺少架構設計、治理中的實際舉措，功能上的變更往往會擊穿多層， 支撐層團隊疲於奔命。例如
企業有多條業務線，各自有不同商品結構， 原各設置一個前台團隊負責其應用的交付和運營。
為降低成本，決定將各業務線的商品展示、搜索等需求集中起來，設立商品中心作為平台支撐層的應用 / 應用組。
這個初衷是好的，但如果商品中心僅僅是「復刻」各業務線的商品結構，而未作相應設計的話，面對多條業務線的多線需求，往往不堪重負，成為瓶頸。
因此商品中心必須設計一個商品結構的元模型，可通過運營人員組裝的方式，為不同業務線的商品結構建模。這樣才能將前台各業務線的商品展示、搜索需求變化就地消化。
因此，如果對分層做出設計，那麼在職責劃分上就要做出應對，否則分層容易成為空中樓閣
4.2.2.5 應用服務與擴展點建模
元模型中的應用服務最主要的作用是顯式地向對外定義一個契約。這在做應用組件升級 /替換、定義IT服務級別等架構治理場景中會有幫助。應用服務可用來對一組相關的應用組件功能集合建模，例如：
在線上訂餐流程中，用戶需要 IT系統支援提交訂單、發起付款、訂單狀態查看、取消訂單四個行為，可將它們建模為應用服務―― 訂餐結賬
應用服務的來源可以是「自動化」的業務服務，如果在業務架構採用了「能力建模」（見 3.2.3.4 能力建模）也可以直接將其構建塊轉換過來：
- 「能力組件」轉換為「應用服務」
- 「基礎能力」轉換為「功能」
另一方面，如果說應用服務顯式定義了應用組件的入口，那麼擴展點則顯式定義了應用組件的出口。擴展點有兩個作用：
一是反轉對不穩定應用組件的依賴，降低其變化對自身的衝擊，這在「應用組件建模」一節中有提到。
二是增強可移植性品質屬性，即不同的業務場景下對於同一個應用組件的邏輯存在差異化需求，對業務架構的「變化點」，根據當前應用狀態上下文中的業務身份，針對性選擇適合的邏輯實現。例如
某公司有零售門店，銷售零售商品，同時在店內還有餐廳，我們可以將客戶結賬識別為一個可共享服務。結賬後，商品訂單需要派單至倉庫提貨，而餐廳訂單需要派單至廚房備餐，這需要使用「放行履約」這個擴展點， 並找到兩種業務模式的擴展實現關係
總結來說，應用服務和擴展點是對邊界概念的加強， 幫助我們理解跨邊界的交互。
4.2.2.6 邊界劃分結果和依據的可視化
我們建議將邊界劃分的結果及過程依據保存下來並可以開放給授權人員訪問。這是因為我們常常見到這樣的問題：「新的功能應該放在哪個應用實現？」
這個問題背後的原因可能是應用的邊界劃分不清晰，職責模糊，或者是邊界劃分的結果及依據丟失了。常見的現象是我們看到一張張應用架構全景圖，由若干個方框組成，代表一個應用或應用組件。由於缺少上下文，僅憑方框內的名字很難判斷應用的職責範圍，所以不好回答「新的功能應該放在哪個應用實現」這樣的問題。
解決這個問題的難點是如何簡練、清晰地描述應用的邊界和職責。在全景圖的基礎上，為每個應用 / 應用組件增加職責描述是一個不錯的起點，但僅用文字描述可能存在歧義。我們建議通過建立應用架構與業務架構、數據架構的構建塊映射來解決這個問題。
通過構建塊映射關係（業務流程使用應用服務，應用服務由應用組件提供，應用組件操作數據對象）， 應用 / 應用組件在業務活動中的職責有了明確的表達，再配合文字來描述引導閱讀和理解，效果更佳。我們推薦為每個應用組 / 應用 / 應用組件建立自己的主頁，將其與其他元素的映射關係作為內容顯示地展示出來
最後，應用架構階段更像是在為 IT 系統應該建設成什麼樣子提出要求，所以應用架構設計應該是和技術實現方案解耦的（雖然技術的升級可能使得應用架構的設計風格產生變化），從而將技術變化隔離在可控範圍內
原文： ThoughtWorks發布《現代企業架構白皮書》 (qq.com)
