現代企業架構架構： https://mp.weixin.qq.com/s/SlrEu0_t0slijrNZ6DP4Ng
業務架構： https://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)
關注我的公衆号
唯有不斷學習方能改變！
--
Ryan Miao