2022現(xiàn)代企業(yè)架構(gòu)框架白皮書

字化型底層法論 皮書目錄引言：再提“業(yè)務(wù)平臺化” 4目錄“中臺”概念的提出、流行到深水區(qū)實踐，折射出本輪數(shù)字化轉(zhuǎn)型中以“業(yè)務(wù)平臺化”為代表的企業(yè)現(xiàn)代化趨勢 5再提業(yè)務(wù)平臺化，是因為深水區(qū)實踐中，新的問題將業(yè)務(wù)平臺化內(nèi)涵向前演進(jìn) 8企業(yè)架構(gòu)設(shè)計方法，是有效的工作方法，經(jīng)典的企業(yè)架構(gòu)框架已不足夠應(yīng)對業(yè)務(wù)平臺化中的新問題 11ThoughtWorks在經(jīng)典企業(yè)架構(gòu)框架基礎(chǔ)上，面向以業(yè)務(wù)平臺化為代表的企業(yè)現(xiàn)代化轉(zhuǎn)型中的新問題，發(fā)布現(xiàn)代企業(yè)架構(gòu)框架 132.現(xiàn)代企業(yè)架構(gòu)框架（ModernEnterpriseArchitectureFramework-MEAF2.現(xiàn)代企業(yè)架構(gòu)框架（ModernEnterprise企業(yè)架構(gòu) 15企業(yè)架構(gòu)框架 15現(xiàn)代企業(yè)架構(gòu)框架 16現(xiàn)代企業(yè)架構(gòu)框架設(shè)計原則 17現(xiàn)代企業(yè)架構(gòu)框架元模型總覽 18現(xiàn)代企業(yè)架構(gòu)框架—業(yè)務(wù)架構(gòu) 20業(yè)務(wù)架構(gòu)元模型綜述 20233業(yè)務(wù)架構(gòu)元模型應(yīng)用 22業(yè)務(wù)架構(gòu)元模型補(bǔ)充說明 39現(xiàn)代企業(yè)架構(gòu)框架—應(yīng)用架構(gòu) 42應(yīng)用架構(gòu)元模型綜述 43應(yīng)用架構(gòu)元模型應(yīng)用 43現(xiàn)代企業(yè)架構(gòu)框架—數(shù)據(jù)架構(gòu) 52數(shù)據(jù)架構(gòu)元模型綜述 53數(shù)據(jù)架構(gòu)元模型應(yīng)用 53現(xiàn)代企業(yè)架構(gòu)框架—技術(shù)架構(gòu) 58技術(shù)架構(gòu)元模型綜述 59技術(shù)架構(gòu)元模型應(yīng)用 597.總結(jié) 688.參考文獻(xiàn)

-------------------------------------------691平臺化”再提“業(yè)務(wù)平臺化”本輪以數(shù)字化驅(qū)動業(yè)務(wù)創(chuàng)新與重塑，越來越清晰的聚焦于：數(shù)字體驗、業(yè)務(wù)平臺化、智能化與云三大領(lǐng)域。盡管不同的行業(yè)、組織和企業(yè)，對上述領(lǐng)域的表述和內(nèi)涵界定可能會存有差異，或仍有其他特定領(lǐng)域的特征顯現(xiàn)，但在我們的觀察中，這三大領(lǐng)域，已在跨行業(yè)范圍內(nèi)形成了較為廣泛的共識。和解決的思路與方法，將賦予現(xiàn)代企業(yè)新的內(nèi)涵。PAGE10PAGE101.1零售、金融、電信為代表的傳統(tǒng)行業(yè)數(shù)字化建設(shè)，中臺實踐正在進(jìn)入到深水區(qū)從2015年開始，以阿里巴巴為代表的各互聯(lián)網(wǎng)巨（理念和相關(guān)實踐開始快速向各行業(yè)滲透和發(fā)展。零售行業(yè)得益于阿里在零售行業(yè)的滲透和影響，以及電商在過去十年的高速發(fā)展，零售行業(yè)最先試水“中臺”。一方面，阿里本身將中臺理念與實踐結(jié)合云服務(wù)向各行業(yè)輸出，同時零售行業(yè)因業(yè)務(wù)模式的相似性，

也具備較好的適配基礎(chǔ)。另一方面，圍繞電商業(yè)務(wù)模式，一系列廠商將其中標(biāo)準(zhǔn)化程度較高的部分快“中心化“商品中心“訂單中心“支付中心”等，以“中臺”的形態(tài)進(jìn)行實施，也在一業(yè)的中臺模型，因其本質(zhì)是對于交易合同及履約的業(yè)務(wù)抽象，具備較廣的適用性，也常被其他行業(yè)借鑒和擴(kuò)展。金融行業(yè)對于金融行業(yè)，打造中臺能力，無論在銀行、證券或是保險等細(xì)分行業(yè)，均已是高度共識的戰(zhàn)略舉措公司時間中臺相關(guān)事件阿里巴巴公司時間中臺相關(guān)事件阿里巴巴2015年12月宣布全面啟動“中臺戰(zhàn)略，構(gòu)建符合大數(shù)據(jù)時代的“大中臺、小前臺”組織機(jī)制和業(yè)務(wù)機(jī)制騰訊2018年9月組織架構(gòu)調(diào)整，“扎根消費互聯(lián)網(wǎng)，擁抱產(chǎn)業(yè)互聯(lián)網(wǎng)”，在技術(shù)上開源節(jié)流，自研上云，全面建設(shè)中臺美團(tuán)2018年11月嘗試打通各個業(yè)務(wù)之間的數(shù)據(jù)，實現(xiàn)用戶端的賬戶統(tǒng)一，實現(xiàn)用戶數(shù)據(jù)中臺京東2018年12月TOB3C電子及消費品零商城市場部等六個核心部門字節(jié)跳動2019年3月搭建“直播大中臺”，“直播大中臺”將抖音、西瓜視頻和火山小視頻三個短視頻產(chǎn)品抽出、(圖1.1-1互聯(lián)網(wǎng)企業(yè)的中臺化大事件)（參考文獻(xiàn)3）之一。（參考文獻(xiàn)4、5）當(dāng)行業(yè)越來越重視客戶一致性體驗，開始打造開放銀行，深度運營客戶，構(gòu)建生態(tài)的同時，對于長期掣肘金融行業(yè)發(fā)展的歷史遺留問題，企業(yè)也深刻意識到對于此類問題解決的迫切性。如龐大的遺留系統(tǒng)難以響應(yīng)前端快速的業(yè)務(wù)創(chuàng)新、客戶和業(yè)務(wù)數(shù)據(jù)孤島現(xiàn)象嚴(yán)重、組織架構(gòu)壁壘高筑等。而中臺建設(shè)被認(rèn)為是行業(yè)普遍認(rèn)同的求解之道，根據(jù)恒生調(diào)研，半數(shù)金融機(jī)構(gòu)正在考慮建設(shè)業(yè)務(wù)中臺，90%金融機(jī)構(gòu)認(rèn)為未來兩至三年會建設(shè)業(yè)務(wù)中臺。（參考文獻(xiàn)4、5）電信行業(yè)IT基礎(chǔ)設(shè)施作為重要支柱的電信行業(yè)，始終保持IT5年，伴隨通信技術(shù)的快速換代所帶來的新的市場特征，圍繞業(yè)務(wù)響應(yīng)力提升和研發(fā)效能改進(jìn)的目標(biāo)，電信IT基礎(chǔ)設(shè)施經(jīng)歷了新一輪的翻新和升級：研發(fā)體系的敏捷轉(zhuǎn)型，DevOps體系搭建、大型核心系統(tǒng)的容器化及服務(wù)化改造。在此基礎(chǔ)上，加之“新基建”頂層設(shè)計的牽引和推動，行業(yè)整體的IT基礎(chǔ)ThoughtWorks在以上行業(yè)中臺建設(shè)的深入實踐認(rèn)為，“中臺”不是目的，而是手段，“平臺化”向業(yè)務(wù)的再演進(jìn)，是本輪數(shù)字化建設(shè)中的重要趨勢回顧ThoughtWorks對于中臺的實踐，我們持續(xù)向行業(yè)輸出一系列思考和洞見的同時，也廣泛且深入

參與了各行業(yè)的數(shù)字化建設(shè)中、尤其是以上三大行業(yè)中領(lǐng)跑企業(yè)的中臺建設(shè)過程。在我們的經(jīng)驗中，不同的行業(yè)，中臺有著不同的最佳適配領(lǐng)域，這里從前面提到的三大行業(yè)中，我們列舉一些各自領(lǐng)域關(guān)注的方向：零售多品牌集團(tuán)型企業(yè)：關(guān)注如何通過中臺建設(shè)，實現(xiàn)集中管控前提下營銷能力在多品牌復(fù)用跨國零售企業(yè)：關(guān)注如何通過中臺建設(shè)，實現(xiàn)全球統(tǒng)一運營下的核心業(yè)務(wù)能力針對中國市場的復(fù)用與差異化適配，以適應(yīng)中國的特有業(yè)務(wù)場景和業(yè)務(wù)發(fā)展（資管）場景的能力抽取與模式復(fù)用，實現(xiàn)對于金融產(chǎn)品的快速創(chuàng)新的加速，和金融電商化的渠道能力運營的加強(qiáng)，為生態(tài)建設(shè)奠定基礎(chǔ)通信企業(yè)：關(guān)注如何實現(xiàn)跨業(yè)務(wù)線之間的公共能力的識別，沉淀，形成統(tǒng)一管控及支撐，實現(xiàn)產(chǎn)品平臺化，更靈活的適配不同場景的需求與快速響應(yīng)。這些領(lǐng)域中，中臺的差異化適配和建設(shè)，印證了中臺實踐已進(jìn)入深水區(qū)。在我們看來，中臺建設(shè)的成功，或者“失敗”，甚至“去中臺化”聲音背后，本質(zhì)上是一致的商業(yè)邏輯：套件實施：臺建不中臺以“復(fù)用”之名起源，因此，一些案例中，很容易走回從前軟件套件實施的思路，以“套件化”的模式，加上一定程度的開放和定制，實現(xiàn)“復(fù)制”套件實施：臺建不與復(fù)用：與復(fù)用：建?！笆恰苯栌梦覀円晃蛔稍儙煹脑挘骸翱瓷先サ哪芰?fù)用是樂高組裝，但真實的能力復(fù)用其實是器官移植，需要的是一場外科手術(shù)。”新的問題將業(yè)務(wù)平臺化內(nèi)涵向前演進(jìn)1.2再提業(yè)務(wù)平臺化，是因為深水區(qū)實踐中，新的問題將業(yè)務(wù)平臺化內(nèi)涵向前演進(jìn)“平臺化”是從信息化到數(shù)字化時代，每一輪IT建設(shè)都會提及的主題之一。而當(dāng)平臺沿著歷史發(fā)展的趨勢繼續(xù)向業(yè)務(wù)的“逼近”過程中，對于平臺抽象和建設(shè)的難度也成指數(shù)型增加，涌現(xiàn)出了一系列新問題。對于這些問題的思考和解決方案的探索，也將賦予業(yè)務(wù)平臺化這個趨勢以新的內(nèi)涵和意義，同時也是我們設(shè)計和發(fā)布新的企業(yè)架構(gòu)框架的起心動念。這些問題的“新”意，更多的體現(xiàn)在“how”上，而不再僅僅是“what”，所以我們以“如何”的句式來逐一總結(jié)和簡述：如何抽離多業(yè)務(wù)線共享的解決方案和能力，集中管控和演進(jìn)，以避免重復(fù)投資？新業(yè)務(wù)如何基于企業(yè)已有的解決方案和能力快速組裝上線，以支撐業(yè)務(wù)快速迭代創(chuàng)新？今天，業(yè)務(wù)發(fā)展和IT建設(shè)的綁定比以往任何時間都更加緊密，而當(dāng)大型企業(yè)的業(yè)務(wù)涉獵已足夠廣泛，多條業(yè)務(wù)線、或者多個業(yè)務(wù)單元并行發(fā)展，IT建設(shè)會隨著業(yè)務(wù)邊界、組織邊界，不可避免的進(jìn)一步分化，也加劇了IT部門進(jìn)行統(tǒng)一管控的困難。一方面，在很多場景中，這樣的分化帶來了雙重投資甚至多重投資的浪費；另一方面也在加劇本就存

在的用戶或者客戶體驗的割裂、數(shù)據(jù)孤島、IT翻新周期長等固有問題。同時，當(dāng)業(yè)務(wù)線不斷嘗試新的業(yè)務(wù)模式，或?qū)τ谝袸T支撐的響應(yīng)力也提出了更高的要求。固有的系統(tǒng)搭建或者產(chǎn)品部署模式，越來越不足以提供及時的響應(yīng)，成本高昂。因此，如何抽離多業(yè)務(wù)線共享的解決方案和能力，集中管控和演進(jìn)，以避免重復(fù)投資？新業(yè)務(wù)如何基于企業(yè)能力快速組裝上線，以支撐業(yè)務(wù)快速迭代創(chuàng)新？是需要解決問題。進(jìn)一步拆解，我們認(rèn)為需要回答：力”模型，以對業(yè)務(wù)進(jìn)行合理的抽象，進(jìn)而識別相似度，抽象與提煉可復(fù)用的業(yè)務(wù)模式；而抽象并沉淀了業(yè)務(wù)能力之后，如何在新的業(yè)務(wù)場景中，識別、復(fù)用已有能力，應(yīng)用、數(shù)據(jù)、技術(shù)及組織應(yīng)該如何予以支撐？以上的工作過程，是否有較好的工作實踐和參考模型？如何合理地劃分IT隨“需”而變的響應(yīng)力除了能力復(fù)用外，另一個提升IT支撐響應(yīng)力的關(guān)鍵是，提升IT系統(tǒng)各組成部分的自治性，使得變更能夠相對獨立的，在更小的邊界范圍內(nèi)，以小步快跑的方式發(fā)生，同時還需要保持一定的一致性，使整體架構(gòu)做到“形散神聚”。因為無論是創(chuàng)新也好，集中管控也好，雖然變化速率不同，但變化始終存在，既然變化不可避免，我們應(yīng)將精力投入到應(yīng)對變化上。而一個清晰的應(yīng)用邊界劃分，可以對于業(yè)務(wù)能力通過對于知識邊界的解耦，實現(xiàn)知識的黑盒復(fù)用，對于變化的響應(yīng)非常有幫助。在我們的經(jīng)驗中，應(yīng)用邊界劃分不合理會對應(yīng)對變化產(chǎn)生明顯的負(fù)面作用。一般來說，邊界的粒度過粗，容易產(chǎn)生功能、運行層面的變更沖突，而邊界這里對各種負(fù)面作用暫不作展開，但它們的共同點IT支撐的響應(yīng)力或穩(wěn)定性。IT系統(tǒng)的應(yīng)用邊界，以合理的布局更好地應(yīng)對變化”是需要解決的問題。進(jìn)一步拆解，我們認(rèn)為需要回答：如何劃分應(yīng)用構(gòu)建塊的邏輯邊界，使其盡可能職責(zé)單一、接口規(guī)范明確，容易變更和組裝？如何組合應(yīng)用構(gòu)建塊成為合適粒度的獨立可部署單元，盡可能減少功能、運行層面的變更沖突？

如何描述、留存以上決策的結(jié)果和依據(jù)，當(dāng)變化發(fā)生時，通過溯源做出優(yōu)質(zhì)的新應(yīng)對？3)如何適當(dāng)拆分過于集中的分析類數(shù)據(jù)處理職責(zé)，以緩解規(guī)模化數(shù)據(jù)分析處理瓶頸？長久以來，業(yè)界對數(shù)據(jù)架構(gòu)的通用做法是：對于運行類（Operational）和分析類（Analytical）場景，應(yīng)該使用不同的設(shè)計方法和技術(shù)支撐。運行類場景以業(yè)務(wù)事務(wù)為主線，關(guān)注點在于業(yè)務(wù)事務(wù)運作證據(jù)的完整性和一致性，以及確保各類數(shù)據(jù)在各業(yè)務(wù)單元間高效、準(zhǔn)確地傳遞，實現(xiàn)跨業(yè)務(wù)單元的事務(wù)推進(jìn)以及對于業(yè)務(wù)溯源的支撐。分析類場景則需要對內(nèi)、外部數(shù)據(jù)進(jìn)行收集和加工，用來度量業(yè)務(wù)運行表現(xiàn)、嘗試分析產(chǎn)生偏差的原因，甚至結(jié)合機(jī)器學(xué)習(xí)等技術(shù)給出對于未來發(fā)展趨勢預(yù)測和判斷，嘗試構(gòu)建數(shù)據(jù)驅(qū)動運營的企業(yè)組織。數(shù)據(jù)想要形成分析類價值，背后需要經(jīng)過攝取（Ingest）-加工（Process）-能力包裝（Serve）AI平臺、數(shù)據(jù)中臺等構(gòu)建模式，它們都有著各自不同的適用場景和技術(shù)棧，針對這些模式的差異我們暫不作展開。由于分析類場景所要求的方法和技術(shù)與運行類場景有著顯著的不同，許多企業(yè)組建了專職的數(shù)據(jù)團(tuán)隊，將分析類數(shù)據(jù)處理工作和其背后的復(fù)雜性打包成為一個黑盒，提供端到端的統(tǒng)一的數(shù)據(jù)類企業(yè)級服務(wù)與支撐。這個模式對于業(yè)務(wù)場景簡單的企業(yè)環(huán)境工作得不錯，但對于多業(yè)務(wù)線、業(yè)務(wù)平臺化的企業(yè)環(huán)境已初顯疲態(tài)。一方面，隨著IT建設(shè)加速，數(shù)據(jù)源和分析類場景的數(shù)量激增，對數(shù)據(jù)類服務(wù)的響應(yīng)力提出了更高要求。另一方面，想要提供高質(zhì)量的數(shù)據(jù)類服務(wù)，除了分析類數(shù)據(jù)的專業(yè)技能，還要求對于業(yè)務(wù)場景、現(xiàn)有應(yīng)用軟件的深入理解。如果所有工作仍然只由專職的集中式團(tuán)隊一肩挑，團(tuán)隊帶寬的限制必然會拖慢響應(yīng)力。因此，我們認(rèn)為需要探索的是如何適當(dāng)拆分過于集中的分析類數(shù)據(jù)處理職責(zé)，為集中式的數(shù)據(jù)團(tuán)隊減4）如何在富技術(shù)時代進(jìn)行平臺型技術(shù)架構(gòu)選型及設(shè)計？受益于云原生架構(gòu)的興起與發(fā)展，新技術(shù)的涌現(xiàn)和不斷成熟，及技術(shù)工具的極大豐富，技術(shù)架構(gòu)設(shè)計的靈活度和效率都得到了顯著提升。

另一方面，在平臺型技術(shù)架構(gòu)的設(shè)計中，作為多業(yè)務(wù)線、多應(yīng)用、多數(shù)據(jù)場景落地的技術(shù)基座，技術(shù)加之“富”技術(shù)條件的加持，技術(shù)架構(gòu)的設(shè)計困難度正呈現(xiàn)指數(shù)級增長。而一直以來，本質(zhì)上是強(qiáng)依賴架構(gòu)師的經(jīng)驗和能力的技術(shù)架構(gòu)設(shè)計方法和過對于架構(gòu)需求把握不足或者沒有架構(gòu)需求的分析意識，過早的進(jìn)入架構(gòu)設(shè)計，導(dǎo)致系統(tǒng)復(fù)雜度變高甚至過度設(shè)計，為開發(fā)落地帶來額外的研發(fā)成本架構(gòu)設(shè)計采用的技術(shù)和工具過于超前，超出團(tuán)隊成員技術(shù)水平，造成落地難度高，新成員上手速度慢，進(jìn)而對整體進(jìn)度和實施效果造成影響架構(gòu)設(shè)計過程時間長，完成后團(tuán)隊就不再愿意對設(shè)計方案繼續(xù)調(diào)整和迭代，當(dāng)技術(shù)發(fā)展變化的困局。因此，我們認(rèn)為架構(gòu)師們比以往，更需要這樣一個體系：沉淀可復(fù)用的架構(gòu)經(jīng)驗沉淀可復(fù)用的架構(gòu)經(jīng)驗結(jié)構(gòu)化的設(shè)計架構(gòu)方案系統(tǒng)性的分析架構(gòu)需求企業(yè)架構(gòu)設(shè)計方法，是有效的工作方法，1.3企業(yè)架構(gòu)設(shè)計方法，是有效的工作方法，中的新問題架構(gòu)框架已不足夠應(yīng)對業(yè)務(wù)平臺化1）以企業(yè)架構(gòu)框架方法進(jìn)行業(yè)務(wù)平臺設(shè)計，是有效的工作方法，且各主流方法各有側(cè)重業(yè)內(nèi)越來越普遍的采用企業(yè)架構(gòu)框架，作為業(yè)務(wù)平臺化整體規(guī)劃指導(dǎo)和方法，這是有效的。因為各類企業(yè)架構(gòu)框架的元模型，大體都可以歸結(jié)為四類視盡管不同框架在具體的層級劃分、及各層結(jié)構(gòu)下的內(nèi)容涵蓋可能會略有不同。這樣的結(jié)構(gòu)較好的匹配了業(yè)務(wù)平臺設(shè)計的問題域。同時各類企業(yè)架構(gòu)框架的工作邏輯相似，均是從愿景與業(yè)務(wù)目標(biāo)出發(fā)自頂向下的貫穿設(shè)計，并保持從業(yè)務(wù)到技術(shù)的一致性，這樣的工作邏輯與業(yè)務(wù)平臺從設(shè)計到落地的邏輯一致。在此基礎(chǔ)上，不同的企業(yè)架構(gòu)框架，由于產(chǎn)生的背景和發(fā)展過程的不同，形成各自的側(cè)重點或行業(yè)屬性，這也從另外一個方面加強(qiáng)了其適用性。例如：Zachman：側(cè)重從利益相關(guān)者的六個視角來描述企業(yè)

TOGAF：強(qiáng)調(diào)企業(yè)架構(gòu)全生命周期治理DoDAF/FEAF-II：面向政府機(jī)構(gòu)的投資組合管理，ViewPointBIAN：面向銀行業(yè)，有銀行業(yè)開箱即用參考模型需要說明的是，以上的側(cè)重總結(jié)，僅代表我們在項目操作中的理解，實際上，每一種框架在框架設(shè)計上都是完備的，在各自的領(lǐng)域和適用場景中也得到了廣泛的應(yīng)用。實操性仍顯不足，且對業(yè)務(wù)平臺化的新問題均沒有特定的設(shè)計和考慮對若干經(jīng)典企業(yè)架構(gòu)框架進(jìn)行對比，從中我們可以清晰的解讀出，在Concept（概念）層面的各項評高中而從Moddling（建模開始，到Process（流程評定開始從M（中）轉(zhuǎn)向L（低），其中和落地的低。(圖1.3-2企業(yè)架構(gòu)框架對比)（參考文獻(xiàn)6）這張表格出自2015年的一篇學(xué)術(shù)文章（參考文獻(xiàn)6），在這之后的5年時間里，各框架也均不同程度地對實操的內(nèi)容進(jìn)行了補(bǔ)充和增強(qiáng)。但從我們的實際的跟進(jìn)研究和項目經(jīng)驗來看，各經(jīng)典框架在項目工程實操性中仍顯不足。這可能也與企業(yè)級架構(gòu)框架的定位相關(guān)，其大多數(shù)的定位都偏向于戰(zhàn)略規(guī)劃和組織級管理與治理，對于架構(gòu)在具體設(shè)計和建模層面都沒有進(jìn)行細(xì)粒度展開。同時，在第二小節(jié)中所提及的，在業(yè)務(wù)平臺化的背景和趨勢下我們所面臨的新問題，也可映射到企業(yè)架構(gòu)框架元模型的四個層次中：業(yè)務(wù)架構(gòu)層：如何抽離多業(yè)務(wù)線共享的能力，以避免重復(fù)投資？新業(yè)務(wù)如何基于企業(yè)能力快速組裝上線，以支撐業(yè)務(wù)快速迭代創(chuàng)新？

應(yīng)用架構(gòu)層：在宏觀規(guī)劃層面，如何有效的劃分和組織能力，如何劃分IT系統(tǒng)的物理邊界，以合理的布局更好地應(yīng)對變化，在局部設(shè)計層面，如何在最大化復(fù)用效果的同時，保障對差異化需求的響應(yīng)力？數(shù)據(jù)架構(gòu)層：如何適當(dāng)拆分過于集中的分析類數(shù)據(jù)處理職責(zé)，緩解規(guī)模化瓶頸技術(shù)架構(gòu)層：如何在富技術(shù)時代進(jìn)行平臺型技術(shù)架構(gòu)設(shè)計這些在當(dāng)前時代背景下廣泛存在的新課題，從各經(jīng)典企業(yè)架構(gòu)框架中也無法直接找到針對性的設(shè)計參1.4ThoughtWorks型中的新問題，發(fā)布現(xiàn)代企業(yè)架構(gòu)框架代化轉(zhuǎn)本白皮書提出的現(xiàn)代企業(yè)架構(gòu)框架就是在這樣的背景下，針對以業(yè)務(wù)平臺化為代表的企業(yè)現(xiàn)代化轉(zhuǎn)型過程中的背景及挑戰(zhàn)，從實踐中探索和總結(jié)出的一套輕量級、敏捷、可落地的企業(yè)架構(gòu)框架方法。整體框架方法設(shè)計保持對經(jīng)典企業(yè)架構(gòu)框架優(yōu)秀設(shè)計部分的傳承，從框架元模型整體結(jié)構(gòu)上，仍遵循應(yīng)用架構(gòu)、數(shù)據(jù)架構(gòu)及技術(shù)架構(gòu)的架構(gòu)視圖分類。而針對業(yè)務(wù)平臺化的特征及新問題，對各層元模型內(nèi)容，進(jìn)行了擴(kuò)展和再定義。

與此同時，這套框架力求實操，對于每一層模型的講解，我們都以問題作為牽引，以解決問題的實操過程作為內(nèi)容串聯(lián)主線。因此，每一個部分的詳細(xì)介紹中，我們按照這樣的順序進(jìn)行講解，先給出該層元模型概覽，之后回顧問題，以問題的解決過程作為牽引，講解元模型的應(yīng)用。PAGE14PAGE142ModernModern（ArchitectureFramework-MEAF）企業(yè)架構(gòu)（EnterpriseArchitecture）始于20世紀(jì)60年代，截至目前已有接近六十年的發(fā)展歷程，作為一門關(guān)鍵的IT學(xué)科領(lǐng)域，經(jīng)過多年的發(fā)展也催生了各類廣泛應(yīng)用于各行業(yè)和應(yīng)用場景的框架與方法論工具，例如Zachman、TOGAF、DoDAF等，這些企業(yè)架構(gòu)框架也一直作為重要的指導(dǎo)方法和工IT但隨著近些年互聯(lián)網(wǎng)的高速發(fā)展，“互聯(lián)網(wǎng)速度”和“產(chǎn)品為王”的理念直入人心，也導(dǎo)致企業(yè)將更多注意力和資源聚焦于產(chǎn)品（系統(tǒng)）架構(gòu)層面，關(guān)注于如何通過合理的系統(tǒng)架構(gòu)設(shè)計幫助產(chǎn)品快速搶占市場和用戶，獲得成功。這樣的產(chǎn)品驅(qū)動型策略，切實幫助了很多企業(yè)快速通過核心產(chǎn)品的構(gòu)建和發(fā)布，迅速占領(lǐng)市場，獲得

了階段性成功。但同樣也是因為缺乏對于企業(yè)級架構(gòu)的整體規(guī)劃與設(shè)計，當(dāng)企業(yè)逐漸深入到可持續(xù)發(fā)展和業(yè)務(wù)持續(xù)拓展階段，產(chǎn)品重復(fù)建設(shè)、技術(shù)與架構(gòu)大規(guī)模異構(gòu)等問題逐漸顯現(xiàn)，給企業(yè)帶來了越來越大的負(fù)擔(dān)，拖慢了企業(yè)持續(xù)發(fā)展和持續(xù)創(chuàng)新的速度。因此，企業(yè)架構(gòu)重新被大家關(guān)注和重視，以互聯(lián)網(wǎng)巨頭為代表開始了一系列的企業(yè)級架構(gòu)重新規(guī)劃和治理的工作，其中“中臺戰(zhàn)略”就是典型的代表。這樣的趨勢也正在從互聯(lián)網(wǎng)行業(yè)蔓延到其他行業(yè)，掀起了一波企業(yè)級架構(gòu)規(guī)劃和治理的新浪潮。至此，企業(yè)架構(gòu)和企業(yè)架構(gòu)框架又重新回歸大家的視野，成為企業(yè)架構(gòu)治理和企業(yè)平臺化轉(zhuǎn)型，乃至企業(yè)數(shù)字化轉(zhuǎn)型的重要理論依據(jù)和指導(dǎo)工具。PAGE15PAGE15企業(yè)架構(gòu)在展開描述企業(yè)架構(gòu)和企業(yè)架構(gòu)框架之前，首先追根溯源，了解一下架構(gòu)的含義，在ISO/IEC/IEEE-42010:2011標(biāo)準(zhǔn)中對于架構(gòu)的定義是：架構(gòu)是系統(tǒng)在其所處環(huán)境中的基本概念或?qū)傩裕w現(xiàn)為它的元素、關(guān)系，以及系統(tǒng)設(shè)計和演進(jìn)的原則。架構(gòu)這個概念源于建筑等其他行業(yè)，隨著計算機(jī)行業(yè)的興起，這樣的概念也被引入到了信息技術(shù)行業(yè)，用于IT系統(tǒng)的設(shè)計。在信息技術(shù)領(lǐng)域大體上主要分為兩個粒度，即：系統(tǒng)架構(gòu)（SystemArchitecture）與企業(yè)架構(gòu)（EnterpriseArchitecture）。信息技術(shù)領(lǐng)域的架構(gòu)設(shè)計本質(zhì)是一個認(rèn)知、抽象與構(gòu)建的過程，即通過對于物理世界的認(rèn)知與抽象，企業(yè)架構(gòu)框架很多人將企業(yè)架構(gòu)（EnterpriseArchitecture）與企業(yè)架構(gòu)框架（EnterpriseArchitectureFramework）的概念混淆，就像很多人容易將敏捷

識別其中的關(guān)鍵概念及其關(guān)系，再通過數(shù)字化的手段在數(shù)字化世界里重新構(gòu)建、模擬和還原。而企業(yè)架構(gòu)同樣作為一種架構(gòu)體系，也依然符合對于架構(gòu)的概念定義，只是將關(guān)注點從系統(tǒng)級別提升到了企業(yè)級別，即企業(yè)架構(gòu)關(guān)注的是在企業(yè)級別的各種視角（viewpoint）及其視圖（view），其中的基本元素及其關(guān)系。通過對于企業(yè)架構(gòu)的規(guī)劃和設(shè)計，可以幫助企業(yè)構(gòu)建整體的數(shù)字化策略，規(guī)劃數(shù)字化項目，通過數(shù)字化的手段幫助其實現(xiàn)期望的戰(zhàn)略目標(biāo)和業(yè)務(wù)結(jié)果，形成企業(yè)的數(shù)字化頂層規(guī)劃與設(shè)計，指導(dǎo)企業(yè)的數(shù)字化轉(zhuǎn)型過程。而這個企業(yè)架構(gòu)規(guī)劃的過程，也被稱為企業(yè)架構(gòu)規(guī)劃(enterprisearchitectureplanning,EAP)。（Agile）與輕量級軟件開發(fā)方法（如Scrum）混淆一樣，其實這是兩個完全不同的概念。企業(yè)架構(gòu)是一門領(lǐng)域?qū)W科，而企業(yè)架構(gòu)框架（例如常見的TOGAF）才是一種具體可實施的框架和方法論，企業(yè)架構(gòu)與企業(yè)架構(gòu)框架的關(guān)系，就類似于敏捷（Agile）與輕量級軟件開發(fā)方法（例如Scrum、XP）的關(guān)系一樣。

在眾多的企業(yè)架構(gòu)框架方法之中，最被大家熟知通用型企業(yè)架構(gòu)框架當(dāng)屬TOGAF，其已經(jīng)成為通用行業(yè)企業(yè)架構(gòu)框架的標(biāo)準(zhǔn)方法。而近些年大量新涌現(xiàn)的輕量級企業(yè)架構(gòu)方法，也大多從TOGAF發(fā)展而來，或是對于TOGAF進(jìn)行擴(kuò)展，或是對于TOGAF進(jìn)行細(xì)化和補(bǔ)充。(圖2.2-1企業(yè)架構(gòu)框架列表)(參考文獻(xiàn)10)現(xiàn)代企業(yè)架構(gòu)框架雖然如上所述，像TOGAF這樣的經(jīng)典企業(yè)架構(gòu)框架從誕生到今已經(jīng)歷了20多年的發(fā)展，在發(fā)展和演進(jìn)過程中也與時俱進(jìn)地加入了對于像SOA等新的架構(gòu)模式的支持。但在具體應(yīng)用框架方法實踐與解決現(xiàn)在化企業(yè)所面臨的問題時，例如如何在云與分布式時代，基于平臺思維進(jìn)行企業(yè)架構(gòu)設(shè)計的過程中仍顯繁重且不完全匹配。終究其原因，這類經(jīng)典企業(yè)架構(gòu)框架所誕生的時代仍處于信息化時代的早期，設(shè)計之初主要面對和解決的是企業(yè)信息化的問題，雖然也在持續(xù)保持演進(jìn)和發(fā)展，但大多以補(bǔ)丁（例如通過元模型擴(kuò)展的方式）的方式予以支持，并不能做到與最新的企業(yè)發(fā)展理念和技術(shù)趨勢無縫融合與原生支持，尤其是在以平臺型為主要特征的現(xiàn)代企業(yè)架構(gòu)的規(guī)劃與設(shè)計過程中，最典型的就是國內(nèi)目前比較廣泛采用的中臺架構(gòu)規(guī)劃過程中，略顯乏力。

因此，不破不立，能否在充分吸收經(jīng)典企業(yè)架構(gòu)框架的優(yōu)秀思想和最佳實踐的前提下，融合最新的企業(yè)數(shù)字化發(fā)展的需求和新技術(shù)新趨勢，勇于跳出TOGAF的限制，從問題出發(fā)，回歸第一性，重新思考和構(gòu)建一個新的輕量級企業(yè)架構(gòu)框架，切實可以解決企業(yè)在向現(xiàn)代企業(yè)架構(gòu)演進(jìn)過程中面臨的問題和挑戰(zhàn)，就成為我們重點關(guān)注和研究的領(lǐng)域。通過幾年的研究實踐，也逐漸形成了一套輕量化、敏捷可落地的企業(yè)架構(gòu)框架方法，我們把它定義為：現(xiàn)代企業(yè)架構(gòu)框架（ModernEnterpriseArchitectureFramework）?，F(xiàn)代企業(yè)架構(gòu)框架設(shè)計原則為了保證框架設(shè)計的有效和易于實施，從框架設(shè)計之初就一直遵循以下框架設(shè)計原則：戰(zhàn)略與業(yè)務(wù)價值驅(qū)動（業(yè)務(wù)驅(qū)動over技術(shù)驅(qū)動）戰(zhàn)略與業(yè)務(wù)價值驅(qū)動，是框架設(shè)計的第一個重要原則，無論是框架本身的設(shè)計還是應(yīng)用框架進(jìn)行企業(yè)級的架構(gòu)規(guī)劃，都需要始終遵循此規(guī)則，使每一個架構(gòu)決策都能回溯到企業(yè)的戰(zhàn)略方向和業(yè)務(wù)價值上。

為了達(dá)到此目標(biāo)，無論是企業(yè)級的應(yīng)用架構(gòu)還是企業(yè)級的技術(shù)架構(gòu)，都需要以支撐企業(yè)級的業(yè)務(wù)架構(gòu)為目標(biāo)，而企業(yè)級的業(yè)務(wù)架構(gòu)要能直接對應(yīng)和反應(yīng)企業(yè)的戰(zhàn)略方向以及業(yè)務(wù)價值體現(xiàn)。一切從業(yè)務(wù)出發(fā)，以價值驅(qū)動，是架構(gòu)設(shè)計的重要原則與基礎(chǔ)。輕量敏捷化（持續(xù)改進(jìn)over一次做對）為保證架構(gòu)的輕量，從框架設(shè)計之初，團(tuán)隊一直反復(fù)審視框架每一個概念和工具的價值和成本，在滿足現(xiàn)代企業(yè)架構(gòu)設(shè)計的前提下，力求用最少的概念和元素解決實際問題。同時如何讓企業(yè)架構(gòu)與敏捷的思想融合，也是我們在框架設(shè)計之初就一直探討和研究的課題。我們希望同時結(jié)合ThoughtWorks在敏捷與企業(yè)架構(gòu)及平臺架構(gòu)各個領(lǐng)域的優(yōu)勢和理解，使現(xiàn)代企業(yè)架構(gòu)框架原生就融入敏捷的思想、原則和最佳實踐，扭轉(zhuǎn)的固有認(rèn)識。為達(dá)到此目標(biāo)，我們將數(shù)據(jù)驅(qū)動、持續(xù)迭代、小步快跑、協(xié)同共創(chuàng)、工作坊等思想、方法和工具也融入到了現(xiàn)代企業(yè)架構(gòu)框架之中，幫助在框架實施過程中實現(xiàn)企業(yè)級架構(gòu)規(guī)劃與建設(shè)的敏捷化?？陕涞兀◤膶嵺`出發(fā)over從理論推導(dǎo)）本框架在設(shè)計過程中的所有元模型定義和方法建

議，都源于實際項目的實踐和提煉，因為可落地易落地也一直是我們構(gòu)建和設(shè)計這個框架的重要原則之一，任何好的概念、思想和工具，如果沒有經(jīng)過實踐的檢驗，也不會被加入到框架的核心模型和要素中來。反映到框架設(shè)計上，從框架的核心元模型出發(fā)，每一個元模型要素都會包含完整的概念定義、應(yīng)用場景、建模語言標(biāo)準(zhǔn)、識別方法與工具建議、輸入基線要求、輸出基線定義，以確保框架的可落地和應(yīng)用此框架設(shè)計與建模的一致性，同時降低框架掌握的門檻，做到易懂、易學(xué)、易用。同時，對于框架從元模型出發(fā)到設(shè)計與建模方法，支持基于企業(yè)的自身特點和不同的戰(zhàn)略目標(biāo)以及業(yè)務(wù)要求，支持對于框架做出適當(dāng)?shù)牟眉簟U(kuò)展和定制，使框架切實成為企業(yè)級架構(gòu)規(guī)劃的有力支撐而非固化限制。現(xiàn)代企業(yè)架構(gòu)框架元模型總覽在展開介紹架構(gòu)之前，我們需要先了解在企業(yè)架構(gòu)領(lǐng)域非常重要的三個概念：元模型（Metamodel），視角（viewpoint）和視圖（View）：元模型（Metamodel）：元模型是對于架構(gòu)核心概念要素的精確定義和描述，元模型構(gòu)成了架構(gòu)設(shè)計的“基本語言要素”，通過元模型及其關(guān)系的表

達(dá)，就可以通過結(jié)構(gòu)化的方式對于架構(gòu)進(jìn)行描述和展現(xiàn)，框架元模型體現(xiàn)了框架設(shè)計者對于企業(yè)級架構(gòu)本身的理解和抽象，是企業(yè)級架構(gòu)框架的核心，是對于架構(gòu)描述的“統(tǒng)一語言”。視角（Viewpoint）：企業(yè)架構(gòu)設(shè)計因為是在對于企業(yè)本身的進(jìn)行架構(gòu)設(shè)計，因其抽象程度較高，同業(yè)務(wù)架構(gòu)業(yè)務(wù)架構(gòu)業(yè)務(wù)身份解決方案應(yīng)用架構(gòu)應(yīng)用組應(yīng)用數(shù)據(jù)架構(gòu)業(yè)務(wù)場景階段活動任務(wù)步驟規(guī)則基礎(chǔ)能力領(lǐng)域?qū)ο蠹夹g(shù)架構(gòu)擴(kuò)展點不變量數(shù)據(jù)對象技術(shù)服務(wù)能力組件應(yīng)用組件數(shù)據(jù)組件數(shù)據(jù)服務(wù)擴(kuò)展點上下文決策模式問題業(yè)務(wù)服務(wù)應(yīng)用服務(wù)擴(kuò)展實現(xiàn)子域應(yīng)用層約束約束架構(gòu)決策規(guī)范資源組織原則愿景（圖2.5-2MEAFMetamodel）時涉及各類不同的干系人和組織，而不同的干系人和組織基于自身所處崗位角色和職責(zé)的不同，對于架構(gòu)的關(guān)注點和視角也存在比較大的差異。因此，通過不同的視角（Viewpoint）的抽象，就可以充分體現(xiàn)我們在審視和進(jìn)行企業(yè)架構(gòu)設(shè)計時，處于什么樣的觀察位置和角度，兼顧不同干系人的架構(gòu)設(shè)計訴求。不同的視角（Viewpoint）會關(guān)注架構(gòu)的不同切面，以及在這個切面下的元模型要素以及他們之間的關(guān)系，這就構(gòu)成了不同的架構(gòu)視圖（View）。視圖（View）：一個視圖描述了從一個或一組相關(guān)的視角（Viewpoint）出發(fā)，通過組合這類視角所關(guān)注的元模型（Metamodel）要素及其關(guān)系，通過設(shè)體現(xiàn)了在一類視角（Viewpoint）下對其關(guān)注的架構(gòu)

元模型要素及其關(guān)系的描述和可視化。在現(xiàn)代企業(yè)架構(gòu)框架（MEAF）的設(shè)計上，我們最大化的延續(xù)和集成了經(jīng)典企業(yè)架構(gòu)框架對于視角（Viewpoint）和視圖（View）的劃分，當(dāng)前版本主要從業(yè)務(wù)架構(gòu)、應(yīng)用架構(gòu)、數(shù)據(jù)架構(gòu)和技術(shù)架構(gòu)出發(fā)四類架構(gòu)視圖出發(fā)，將關(guān)注點聚焦于在不同架構(gòu)視圖下，針對平臺型企業(yè)架構(gòu)設(shè)計這個大的前提和背景，如何設(shè)計和應(yīng)用元模型（Metamodel）重新對于企業(yè)架構(gòu)建模，滿足企業(yè)對于現(xiàn)代企業(yè)架構(gòu)設(shè)計的需求的同時，保證企業(yè)架構(gòu)設(shè)計的可落地。下面就將根據(jù)不同的視圖（View）以元模型（Metamodel）為主線，展開詳細(xì)介紹現(xiàn)代企業(yè)架構(gòu)框架（MEAF）的架構(gòu)設(shè)計要素和應(yīng)用場景。PAGE20PAGE203構(gòu)框架業(yè)務(wù)架構(gòu)元模型綜述業(yè)務(wù)架構(gòu)(BusinessArchitecture)定義了企業(yè)各類業(yè)務(wù)的運作模式及業(yè)務(wù)之間的關(guān)系結(jié)構(gòu)。它以承接企業(yè)戰(zhàn)略為出發(fā)點，以支撐實現(xiàn)企業(yè)戰(zhàn)略為目標(biāo)，通過對于業(yè)務(wù)能力的識別與構(gòu)建，并將業(yè)務(wù)能力以業(yè)務(wù)服務(wù)的方式透出，實現(xiàn)對于業(yè)務(wù)流程的支撐，并最終通過組織給予保障。

業(yè)務(wù)架構(gòu)是企業(yè)架構(gòu)的核心內(nèi)容，直接決定了企業(yè)戰(zhàn)略的實現(xiàn)能力，是其他架構(gòu)領(lǐng)域工作的前提條件和架構(gòu)設(shè)計的主要依據(jù)。“服務(wù)3.1-1所示：PAGE21PAGE21階段活動任務(wù)步驟規(guī)則流程服務(wù)業(yè)務(wù)服務(wù)組織組織單元崗位角色流程服務(wù)業(yè)務(wù)服務(wù)組織組織單元崗位角色領(lǐng)域子域領(lǐng)域?qū)ο箢I(lǐng)域事件能力擴(kuò)展點流程通用流程可變點er）業(yè)務(wù)業(yè)務(wù)身份擴(kuò)展實現(xiàn)業(yè)務(wù)組合管理業(yè)務(wù)群業(yè)務(wù)場景其中“模式”部分是我們?yōu)椤捌脚_型”企業(yè)架構(gòu)設(shè)計的核心解決方案，包括：解決方案建模解決方案建模能力組件建模擴(kuò)展點與擴(kuò)展實現(xiàn)建?；A(chǔ)能力建模Part4能力建模Part3業(yè)務(wù)身份建模Part2領(lǐng)域建模Part1流程建?，F(xiàn)代業(yè)務(wù)架構(gòu)典型問題在幫助企業(yè)構(gòu)建業(yè)務(wù)架構(gòu)的過程中，我們發(fā)現(xiàn)大部分企業(yè)正面臨共同的問題：如何抽離多業(yè)務(wù)線共享的能力，集中管控和演進(jìn)，以避免重復(fù)投資？新業(yè)務(wù)如何基于企業(yè)能力快速組裝上線，以支撐業(yè)務(wù)快速迭代創(chuàng)新？問題的背景和起因在于，當(dāng)大型企業(yè)的業(yè)務(wù)發(fā)展到達(dá)一定規(guī)模，多條業(yè)務(wù)線并存、或多個業(yè)務(wù)單元并行發(fā)展，IT建設(shè)會隨著業(yè)務(wù)邊界、組織邊界，不可避免的進(jìn)一步分化，也加劇了IT部門進(jìn)行統(tǒng)一管控的困難。一方面，在很多場景中，這樣的分化帶來了雙重投資甚至多重投資的浪費，另一方面也在加劇本就存在的用戶或者客戶體驗的割裂、數(shù)據(jù)孤島、IT翻新周期長等固有問題。同時，當(dāng)業(yè)務(wù)線不斷嘗試新的業(yè)務(wù)模式，或?qū)τ谝袸T支撐的響應(yīng)力也提出了更高的要求。固有的系統(tǒng)搭建或者產(chǎn)品部署模式，越來越不足以提供及時的響應(yīng)，成本高昂。為了解決上述問題，我們對問題進(jìn)行了進(jìn)一步拆解：Q1：什么是可共享復(fù)用的能力？

Q2：如何識別和構(gòu)建能力？Q3：如何使用能力，實現(xiàn)新業(yè)務(wù)快速上線？在對問題進(jìn)行上述拆解后，我們將基于業(yè)務(wù)架構(gòu)元模型逐一解決。什么是可共享復(fù)用的能力？在現(xiàn)代企業(yè)架構(gòu)中，面向能力的規(guī)劃超越面向功能與服務(wù)的規(guī)劃成為企業(yè)級業(yè)務(wù)架構(gòu)規(guī)劃的關(guān)注要點，如何基于能力的識別與規(guī)劃，最大化的沉淀企業(yè)級可復(fù)用的能力，并通過擴(kuò)展、編排和組合等形式應(yīng)用到更多的場景，是平臺型企業(yè)架構(gòu)需要解決的關(guān)鍵問題。需要在平臺上構(gòu)建可復(fù)用的“能力”以及為能力提供必要的擴(kuò)展與可變機(jī)制，以此為不同前臺提供靈活多變的業(yè)務(wù)服務(wù)，滿足不同前臺差異化個性化的的需求。而“能力”根據(jù)粒度的不同，可再度細(xì)分為“基礎(chǔ)能力”、“能力組件”和“解決方案”三個層級。不同業(yè)務(wù)的差異性，則可通過能力的“擴(kuò)展點”設(shè)計和不同“業(yè)務(wù)身份”在擴(kuò)展點上的“擴(kuò)展實現(xiàn)”進(jìn)行區(qū)分?？傮w實現(xiàn)機(jī)制如下：業(yè)務(wù)身份定制化業(yè)務(wù)身份定制化客能力 解決方案 被..編排能力組件被..編排基礎(chǔ)能力擴(kuò)展點被復(fù)用XX業(yè)務(wù)應(yīng)用配置下發(fā)配置業(yè)務(wù)身份對應(yīng)的擴(kuò)展實現(xiàn)(圖3.2-2企業(yè)能力共享復(fù)用的實現(xiàn)機(jī)制)“業(yè)務(wù)身份業(yè)務(wù)平臺在對各業(yè)務(wù)同時提供服務(wù)時，需要能區(qū)分每一次業(yè)務(wù)服務(wù)請求的業(yè)務(wù)身份要素，以便提供差異化個性化的服務(wù)；因此需要對企業(yè)各業(yè)務(wù)的身份業(yè)務(wù)身份是業(yè)務(wù)在平臺中的代名詞，是在業(yè)務(wù)運營中唯一區(qū)分某個具體業(yè)務(wù)的ID。平臺基于業(yè)務(wù)身份匹配該特定業(yè)務(wù)的流程和業(yè)務(wù)規(guī)則，并基于業(yè)務(wù)身基礎(chǔ)能力：是對領(lǐng)域?qū)ο蟮脑硬僮?，完成一個領(lǐng)域?qū)ο笊蠁我磺彝暾穆氊?zé)。比如：創(chuàng)建售后單、能力組件：能力組件是對基礎(chǔ)能力的進(jìn)一步封裝，第一類能力組件是根據(jù)業(yè)務(wù)服務(wù)的需要編排封裝的

訂單創(chuàng)建能力組件。第二類能力組件是平臺針對一系列緊密關(guān)聯(lián)的業(yè)務(wù)活動，設(shè)計的能力模板，可基于該模板快速定制某個具體業(yè)務(wù)的特定流程和能合支付”、“快速建站”等能力組件。能力組件加不再需要耗費精力在理解平臺大量的基礎(chǔ)能力上。擴(kuò)展點與擴(kuò)展實現(xiàn)：“擴(kuò)展點”是對基礎(chǔ)能力的可變性設(shè)計，在技術(shù)側(cè)體現(xiàn)為基礎(chǔ)能力實現(xiàn)中的某一展實現(xiàn)”。比如：訂單渲染基礎(chǔ)能力中有一個步驟是訂單總價試算，而正常時期的總價試算規(guī)則與秒殺時期的總價試算規(guī)則是不同的，因此需要對訂單并分別定義在正常時期和秒殺時期的擴(kuò)展實現(xiàn)。解決方案：是平臺針對一類共性業(yè)務(wù)的端到端過程設(shè)計的能力模板；可基于該模板快速定制某個具體業(yè)務(wù)的特定能力和流程，從而達(dá)到業(yè)務(wù)模式級別復(fù)用的目的。比如：虛擬物品交易解決方案。如何識別和構(gòu)建能力？兩個階段。

在業(yè)務(wù)梳理階段：對企業(yè)業(yè)務(wù)、流程、組織、業(yè)務(wù)服務(wù)和業(yè)務(wù)規(guī)則進(jìn)行細(xì)致完整地梳理，作為后續(xù)模式設(shè)計的基礎(chǔ)和輸入。而在模式設(shè)計階段：則會通過流程建模、領(lǐng)域建模、業(yè)務(wù)身份建模和能力建模4個步驟完成企業(yè)能力的識別構(gòu)建。流程具體過程如下：流程業(yè)務(wù)組合管理業(yè)務(wù)群業(yè)務(wù)場景 階段活動任務(wù)步驟規(guī)則 業(yè)務(wù)組合管理業(yè)務(wù)群業(yè)務(wù)場景階段活動任務(wù)步驟規(guī)則組織崗位角色服務(wù)業(yè)務(wù)服務(wù)業(yè)務(wù)梳理業(yè)務(wù)梳理模式設(shè)計1 2 3 41234流程建模通用流程設(shè)計可變點設(shè)計 領(lǐng)域建模子域劃分領(lǐng)域?qū)ο笞R別流程建模通用流程設(shè)計可變點設(shè)計領(lǐng)域建模子域劃分領(lǐng)域?qū)ο笞R別領(lǐng)域事件識別業(yè)務(wù)身份建模業(yè)務(wù)定義要素解析規(guī)則定義能力建模解決方案設(shè)計能力組件設(shè)計點設(shè)計(圖3.2-3識別和構(gòu)建能力的過程)模式設(shè)計階段中：設(shè)計可變點，作為可復(fù)用性分析的基礎(chǔ)。領(lǐng)域建模：負(fù)責(zé)基于流程建模結(jié)果，識別領(lǐng)域事件和領(lǐng)域?qū)ο螅澐肿佑虻倪吔纾活I(lǐng)域?qū)ο髽?gòu)成了提供可復(fù)用能力的基本單元，對領(lǐng)域?qū)ο蟮牟僮骷词腔A(chǔ)能力。業(yè)務(wù)身份建模：負(fù)責(zé)定義業(yè)務(wù)身份識別的要素和業(yè)務(wù)身份解析規(guī)則，用于給可復(fù)用的能力區(qū)分不同的業(yè)務(wù)身份要素。通用流程階段規(guī)則同一共性分類下的業(yè)務(wù)AA流程規(guī)則步驟任務(wù)活動階段能力建模：負(fù)責(zé)最終完成平臺三類可復(fù)用能力的設(shè)計，即通用流程階段規(guī)則同一共性分類下的業(yè)務(wù)AA流程規(guī)則步驟任務(wù)活動階段

下面將詳細(xì)說明各步驟的實施方法：流程建模為了提取可復(fù)用的能力，首先需要識別共性業(yè)務(wù)，然后將同一類共性的業(yè)務(wù)抽象提煉出通用流程，并基于通用流程進(jìn)行可變性分析。具體方法是按業(yè)務(wù)架構(gòu)中流程部分的元模型（階段、活動、任務(wù)、步驟、業(yè)務(wù)規(guī)則），結(jié)合自上而下以及自下而上的方式逐層提煉收斂通用模型和可變點。總體實現(xiàn)機(jī)制如下：業(yè)務(wù)業(yè)務(wù)群業(yè)務(wù)提取共性業(yè)務(wù)業(yè)務(wù)業(yè)務(wù)群業(yè)務(wù)

層抽象提煉同一共性分類下的業(yè)務(wù)BB流程階段活動規(guī)則同一共性分類下的業(yè)務(wù)BB流程階段活動規(guī)則步驟任務(wù)可變點(圖3.2-4流程建模的總體實現(xiàn)機(jī)制)可變點V可變點實現(xiàn)2可變點實現(xiàn)1VP可變性模型可變點V可變點實現(xiàn)2可變點實現(xiàn)1VP可變性模型可變點關(guān)系可變點實現(xiàn)（V）怎么變怎么變可變性可變點（VP）(圖3.2-5可變性模型的組成部分)綜上所述，流程建模的主要步驟如下：分析業(yè)務(wù)組合，提取共性業(yè)務(wù)。抽象提煉通用步驟和業(yè)務(wù)實體；識別各業(yè)務(wù)的差異部分，提煉設(shè)計可變點，確定可變點實現(xiàn)和關(guān)系。分析所有共性業(yè)務(wù)的各流程任務(wù)，抽象提煉通用任務(wù)；識別各業(yè)務(wù)在任務(wù)上的差異部分。分析所有共性業(yè)務(wù)的各流程活動，抽象提煉通用活動；識別各業(yè)務(wù)在活動上的差異部分。分析所有共性業(yè)務(wù)的各流程階段，抽象提煉通用階段；識別各業(yè)務(wù)在階段上的差異部分。

領(lǐng)域建模領(lǐng)域是指組織的業(yè)務(wù)范圍以及在其中所進(jìn)行的活動，也就是平臺能力需要支撐的業(yè)務(wù)范圍。因此，為了構(gòu)建出平臺能力，需要對業(yè)務(wù)領(lǐng)域進(jìn)行深入的理解和設(shè)計。在業(yè)務(wù)架構(gòu)部分，將進(jìn)行領(lǐng)域戰(zhàn)略層級的建模，主要包括：“子域”、“領(lǐng)域?qū)ο蟆?、“領(lǐng)域事件”部分的設(shè)計。 子域 領(lǐng)域?qū)ο?領(lǐng)域事件領(lǐng)域(圖3.2-6領(lǐng)域戰(zhàn)略層級建模的組成部分)領(lǐng)域戰(zhàn)略層級建模的過程如下： 領(lǐng)域事件 領(lǐng)域?qū)ο? 子域 領(lǐng)域(圖3.2-7領(lǐng)域戰(zhàn)略層級建模的過程)領(lǐng)域事件識別領(lǐng)域事件（DomainEvent）：是領(lǐng)域?qū)＜谊P(guān)心的，在業(yè)務(wù)上真實發(fā)生的事件，這些事件對系統(tǒng)會產(chǎn)生重要的影響，如果沒有這些事件的發(fā)生，整個業(yè)務(wù)邏輯和系統(tǒng)實現(xiàn)就不能成立。我們可以通過領(lǐng)域事件對過去發(fā)生的事情進(jìn)行溯源，因為過去所發(fā)生的對業(yè)務(wù)有意義的信息都會通過某種形式保存下來。比如：“用戶地址已更新”、“訂單已發(fā)貨”等領(lǐng)域事件。領(lǐng)域事件對系統(tǒng)常見的影響有：對內(nèi)產(chǎn)生了某種數(shù)據(jù)觸發(fā)了某種流程或事情狀態(tài)發(fā)生了某種變化

對外發(fā)送了某些消息目前比較常用的領(lǐng)域事件識別方法是“事件風(fēng)暴（EventStorming）”，主要步驟如下：邀請業(yè)務(wù)專家（或領(lǐng)域?qū)＜遥┖图夹g(shù)專家共同明確和選擇需要分析的業(yè)務(wù)場景。確定起始事件和結(jié)束事件，事件以“X已YYY”的形式進(jìn)行命名（的中文表達(dá)方法）。根據(jù)場景和業(yè)務(wù)復(fù)述的復(fù)雜度，決定以時間線的哪個方向開始梳理事件（正向或逆向）。以先發(fā)散再收斂的方式，按照時間線的先后順序和并行關(guān)系，補(bǔ)充和完善領(lǐng)域事件。“X的名詞形式進(jìn)行命名。完成一遍事件梳理之后，通過問問題的方式，逆向檢查（ReverseCheck）事件流的邏輯合理性，例如：該事件真的需要在系統(tǒng)實現(xiàn)的時候考慮嗎？該事件如果存在，那它的前提條件是什么？是？重復(fù)以上步驟，迭代式的完成全部領(lǐng)域事件的識別。領(lǐng)域事件識別的示例如下：建建加建定付減貨貨銷復(fù)訴訴受理(圖3.2-8領(lǐng)域事件識別的示例)領(lǐng)域?qū)ο笞R別（nt作為業(yè)務(wù)和系統(tǒng)實現(xiàn)的核心聯(lián)系，領(lǐng)域?qū)ο蠓庋b和承載了業(yè)務(wù)邏輯，是系統(tǒng)設(shè)計的基礎(chǔ)。領(lǐng)域建模中重要的部分之一就是對“領(lǐng)域?qū)ο箢I(lǐng)域?qū)ο笾g關(guān)系的識別和設(shè)計。而領(lǐng)域?qū)ο笞R別將基于前面領(lǐng)域事件識別的結(jié)果開展。領(lǐng)域?qū)ο螅ǔ０ǖ幌抻冢侯I(lǐng)域事件中出現(xiàn)了的名詞；如果沒有信息系統(tǒng)，在現(xiàn)實中會看得見摸得著的事物（例如訂單）；雖然在當(dāng)前業(yè)務(wù)中看不見摸不著，但是可以在未來抽象出來的業(yè)務(wù)概念。

在領(lǐng)域驅(qū)動設(shè)計（Domain-DrivenDesign）（參考文獻(xiàn)7）中一般存在三類領(lǐng)域?qū)ο螅壕酆细菏穷I(lǐng)域?qū)ο蟮母?jié)點，具有全局標(biāo)識，對象其它的實體只能通過聚合根來導(dǎo)航；如訂單可以分為訂單頭和訂單行，訂單頭是聚合根，它包含了訂單基本信息；訂單行是實體，它包含訂單的明細(xì)信息，聚合跟所代表的聚合實現(xiàn)了對于業(yè)務(wù)一致性的保障，是業(yè)務(wù)一致性的邊界。實體：是領(lǐng)域?qū)ο蟮闹鞲?，具有唯一?biāo)識和生命周期，可以通過標(biāo)識判斷相等性，并且是可變的，如常見的用戶實體、訂單實體；值對象：實體的附加業(yè)務(wù)概念，用來描述實體所包含的業(yè)務(wù)信息，無唯一標(biāo)識，可枚舉且不可變，如收貨地址、合同種類等等。業(yè)務(wù)架構(gòu)只負(fù)責(zé)初步和整體識別領(lǐng)域?qū)ο螅鴮︻I(lǐng)域?qū)ο蟮姆诸悾ň酆细?、實體、值對象）和戰(zhàn)術(shù)層級的詳細(xì)設(shè)計將在應(yīng)用架構(gòu)設(shè)計部分完成。領(lǐng)域?qū)ο笞R別的主要步驟如下：對每一個領(lǐng)域事件，快速識別或抽象出與該領(lǐng)域事件最相關(guān)（或隱含的）的業(yè)務(wù)概念，并將其以名詞形式予以貼出。檢查領(lǐng)域名詞和領(lǐng)域事件在概念和粒度（例如數(shù)量，單數(shù)還是集合）上的一致性，通過重命名的方式統(tǒng)一語言，消除二義性。

訂單提交 訂單提交 投訴已創(chuàng)建單已支付已撤銷已投訴待辦 已接受投訴單處理已處理已配貨物已發(fā)貨如果在討論過程中，有任何因為問題澄清和知識增長帶來的對于之前各種產(chǎn)出物的共識性調(diào)整，請不要猶豫，立刻予以調(diào)整和優(yōu)化。重復(fù)以上步驟，迭代式的完成全部領(lǐng)域?qū)ο蟮淖R別。

貨物

貨(圖3.2-9領(lǐng)域?qū)ο笞R別的示例)領(lǐng)域?qū)ο笞R別的示例如下： 3.2.3.2.3子域劃分商品(SPU)商品(SPU)商品建“訂單子域”、“物流子域”等，子域的劃分仍屬庫存(SKU)庫存(SKU)復(fù)加減supportingsubdomaindomain定subdomaingenericsubdomain(圖3.2-10子域的類型)核心域（CoreDomain）：是當(dāng)前產(chǎn)品的核心差異化競爭力，是整個業(yè)務(wù)的盈利來源和基石，如果核心域不存在那么整個業(yè)務(wù)就不能運作。對于核心域，需要投入最優(yōu)勢的資源（包括能力高的人），和做嚴(yán)謹(jǐn)良好的設(shè)計。支撐域（SupportingSubdomain）：解決的是支撐核心域運作的問題，其重要程度不如核心域，但具備強(qiáng)烈的個性化需求，難以在業(yè)內(nèi)找到現(xiàn)成的解決方案，需要專門的團(tuán)隊定制開發(fā)。通用域（GenericSubdomain）：該類問題在業(yè)內(nèi)非常常見，所以很可能有現(xiàn)成的解決方案，通過購買或簡單修改的方式就可以使用。子域劃分的示例如下：

子域劃分的主要步驟如下：根據(jù)“每一個問題子域負(fù)責(zé)解決一個有獨立業(yè)務(wù)價值的業(yè)務(wù)問題”的視角出發(fā)，可以通過疑問句的方式來澄清和分析子域需要解決的業(yè)務(wù)問題，例如“如何進(jìn)行庫存管理？（英文描述Howto…？）”。利用虛線，將解決同一個業(yè)務(wù)問題的限界上下X的形式對每個子域進(jìn)行命名。根據(jù)三種類型的子域定義，共同結(jié)合業(yè)務(wù)實際（或者參考設(shè)計思維中的電梯演講），確定每個子域的子域類型。通域支付上下文支付寶售后上下文退貨商品退貨單采購上下文補(bǔ)貨單采購單商品上下文礎(chǔ)信息運營子域物流上下文發(fā)貨單貨運商品物流子域銷售上下文訂單銷售商品核域順豐客服上下文投訴單庫管上下文客服子域庫管子域配貨單庫存商品物流服務(wù)子域入庫單出庫單(圖3.2-11子域劃分的示例)業(yè)務(wù)身份ID業(yè)務(wù)身份ID業(yè)務(wù)身份名稱領(lǐng)域?qū)ο竺Q領(lǐng)域?qū)ο驛屬性1屬性2屬性3屬性4“條件規(guī)則例如<1000”1（卡會員’）”“條件規(guī)則1（<100天…條件規(guī)則2…2（卡會員’）”…………領(lǐng)域?qū)ο竺Q領(lǐng)域?qū)ο驜屬性1屬性2屬性3屬性4條件規(guī)則1………條件規(guī)則2…業(yè)務(wù)身份由“業(yè)I”、“業(yè)務(wù)身份名稱”、四個部分組成。道等業(yè)務(wù)身份業(yè)務(wù)身份識別解析規(guī)則業(yè)務(wù)身份識別解析規(guī)則(圖3.2-12業(yè)務(wù)身份的組成部分)其中，業(yè)務(wù)身份要素定義是最基礎(chǔ)、也是最難的部分。企業(yè)應(yīng)根據(jù)自身業(yè)務(wù)特征對身份要素進(jìn)行識別定義，常見的身份要素維度包括但不限于：客戶、產(chǎn)品和渠道等。業(yè)務(wù)身份要素除了對要素維度進(jìn)行抽取識別，還需要定義每個要素維度所包含的領(lǐng)域?qū)ο螅òI(lǐng)域?qū)ο蟮膶傩裕?；這些領(lǐng)域?qū)ο蠹捌鋵傩杂脕矶x業(yè)務(wù)身份的識別解析規(guī)則。實現(xiàn)機(jī)制如下：

(圖3.2-13業(yè)務(wù)身份解析機(jī)制)業(yè)務(wù)身份名稱業(yè)務(wù)身份名稱業(yè)務(wù)身份ID分析業(yè)務(wù)組合，提取業(yè)務(wù)身份要素維度。確定各業(yè)務(wù)身份要素維度對應(yīng)的領(lǐng)域?qū)ο螅òI(lǐng)域?qū)ο蟮膶傩裕?。確定領(lǐng)域?qū)ο蟾鲗傩缘娜≈禇l件規(guī)則，定義業(yè)務(wù)身份識別解析規(guī)則。指定業(yè)務(wù)身份名稱。ID。能力建模能力建模分為“基礎(chǔ)能力和擴(kuò)展點設(shè)計”、“能力序如下：擴(kuò)展點設(shè)計能力建?；A(chǔ)能力設(shè)計能力組件設(shè)計解決方案設(shè)計(圖3.2-14能力建模的過程順序)基礎(chǔ)能力與擴(kuò)展點設(shè)計基礎(chǔ)能力：是對領(lǐng)域?qū)ο蟮脑硬僮?，完成一個領(lǐng)域上單一且完整的職責(zé)。比如：創(chuàng)建售后單、修改商品庫存量等。擴(kuò)展點與擴(kuò)展實現(xiàn)：“擴(kuò)展點”是對基礎(chǔ)能力的可變性設(shè)計，在技術(shù)側(cè)體現(xiàn)為基礎(chǔ)能力實現(xiàn)中的某一個步驟的接口定義，而接口的一個實現(xiàn)為一個“擴(kuò)展實現(xiàn)”。比如：訂單渲染基礎(chǔ)能力中有一個步驟是訂單總價試算，而正常時期的總價試算規(guī)則與秒殺時期的總價試算規(guī)則是不同的，因此需要對訂單并分別定義在正常時期和秒殺時期的擴(kuò)展實現(xiàn)。

不同的業(yè)務(wù)通過使用同一個基礎(chǔ)能力來達(dá)成共享復(fù)用的目的，而不同業(yè)務(wù)在業(yè)務(wù)規(guī)則上的差異性，則通過定義該基礎(chǔ)能力在擴(kuò)展點上的不同擴(kuò)展實現(xiàn)來區(qū)分。需要注意的是，通常這套機(jī)制需要技術(shù)上的開發(fā)框架支持?；A(chǔ)能力與擴(kuò)展點設(shè)計的主要步驟如下：驟，確定其對應(yīng)的領(lǐng)域?qū)ο螅ㄗ⒁?，該領(lǐng)域?qū)ο髴?yīng)來自于前面的領(lǐng)域建模步驟）。根據(jù)步驟對領(lǐng)域?qū)ο蟮牟僮?，設(shè)計對應(yīng)的基礎(chǔ)能力；基礎(chǔ)能力的設(shè)計應(yīng)遵循如下原則：完成對一個領(lǐng)域?qū)ο髥我磺彝暾牟僮髀氊?zé)基礎(chǔ)能力操作的領(lǐng)域?qū)ο笞畲蟛荒艹鰡蝹€聚合，最小不能破壞業(yè)務(wù)的一致性要求基礎(chǔ)能力的輸入與輸出建議對象化，以規(guī)范使用根據(jù)流程建模步驟中識別出的與該基礎(chǔ)能力有關(guān)的可變點，以及各業(yè)務(wù)身份在該可變點上不同的業(yè)務(wù)規(guī)則，提煉設(shè)計出基礎(chǔ)能力的擴(kuò)展點確定擴(kuò)展點的默認(rèn)實現(xiàn)（即默認(rèn)情況下基礎(chǔ)能力執(zhí)行的業(yè)務(wù)規(guī)則）能力組件設(shè)計能力組件：是對基礎(chǔ)能力的進(jìn)一步封裝，目的是方便業(yè)務(wù)的使用。能力組件加快了業(yè)務(wù)接入平臺的速度，讓業(yè)務(wù)側(cè)專注業(yè)務(wù)本身，不再需要耗費精力在理解平臺大量的基礎(chǔ)能力上。能力組件按封裝粒度不同分為兩類：

比如：訂單創(chuàng)建能力組件。第二類能力組件是平臺針對一系列緊密關(guān)聯(lián)的業(yè)務(wù)活動，設(shè)計的能力模板，可基于該模板快速定制某個具體業(yè)務(wù)的特定流程和能力，從而達(dá)到復(fù)用全部“快速建站”等能力組件。實現(xiàn)機(jī)制及示例如下：購物車結(jié)算結(jié)算頁Web訂單提交購物車結(jié)算結(jié)算頁Web訂單提交車Promise管理車占用創(chuàng)建創(chuàng)建添加購物車試算訂單修改添加校驗訂驗態(tài)修改創(chuàng)建修改態(tài)訂單創(chuàng)建庫存 訂購物車Web拆單添加商品修改總價試算修改扣減商品創(chuàng)建??創(chuàng)建態(tài)校驗校驗入物車價態(tài)校驗訂單運營我的訂單Web訂單履行修改 分發(fā) 排程 加工 服務(wù)基礎(chǔ)能力基礎(chǔ)能力與能力組件的設(shè)計都基于流程建模和領(lǐng)域建模的結(jié)果，各設(shè)計產(chǎn)出要素的對應(yīng)關(guān)系如下：被..編排能力組件（第一類）被..編排基礎(chǔ)能力 擴(kuò)展點領(lǐng)域?qū)ο箢I(lǐng)域事件能力建模領(lǐng)域建模能力建模領(lǐng)域?qū)ο箢I(lǐng)域事件能力建模領(lǐng)域建模能力建模規(guī)則可變點通用流程流程建模步驟任務(wù)活動階段能力組件（第二類）能力組件設(shè)計的主要步驟如下：對流程建模中輸出的每個任務(wù)，設(shè)計其所需的業(yè)務(wù)服務(wù)，可采用服務(wù)藍(lán)圖的方法進(jìn)行業(yè)務(wù)服務(wù)設(shè)計。對每個業(yè)務(wù)服務(wù)，封裝編排滿足其需求的一組基礎(chǔ)能力成為第一類能力組件。對流程建模中輸出的階段和業(yè)務(wù)活動進(jìn)行逐項分析，從價值交付和階段性價值交付的角度，識別對應(yīng)的一系列緊密關(guān)聯(lián)的業(yè)務(wù)活動；將這些業(yè)務(wù)活動包含涉及的所有能力組件和基礎(chǔ)能力封裝定義為第二類能力組件。

解決方案設(shè)計解決方案：是平臺針對一類共性業(yè)務(wù)的端到端過程設(shè)計的能力模板；可基于該模板快速定制某個具體業(yè)務(wù)的特定能力，從而達(dá)到業(yè)務(wù)模式復(fù)用的目的。比如：虛擬物品交易解決方案。從以上定義可以看出，解決方案的核心是對共性業(yè)務(wù)進(jìn)行識別提取和對業(yè)務(wù)全部能力進(jìn)行模板化封裝。 建模封裝化領(lǐng)域?qū)ο箢I(lǐng)域事件建模封裝化領(lǐng)域?qū)ο箢I(lǐng)域事件能力建模基礎(chǔ)能力被..編排被..編排擴(kuò)展點能力建模）可變點通用流程流程規(guī)則步驟任務(wù)活動階段解決方案業(yè)務(wù)業(yè)務(wù)組合管理業(yè)務(wù)群業(yè)務(wù)C?業(yè)務(wù)N業(yè)務(wù)A業(yè)務(wù)B共性業(yè)務(wù)共性業(yè)務(wù) 模建解決方案設(shè)計的主要步驟如下：識別和提取共性業(yè)務(wù)。

（圖3.2-17解決方案設(shè)計的過程）價值價值業(yè)務(wù)特征復(fù)用對象層級復(fù)用對共性業(yè)務(wù)進(jìn)行流程建模和領(lǐng)域建模，具體方法參見前面所述。進(jìn)行基礎(chǔ)能力和擴(kuò)展點設(shè)計。

能力 基礎(chǔ)能共享 領(lǐng)域模

支持同一個業(yè)務(wù)場景的 多個能力消費者，主要解決數(shù)據(jù)一致性問題。如常見的全渠道策略下，多個渠道客戶端使進(jìn)行能力組件設(shè)計。

用同一個服務(wù)端能力 基于通用流程，將共性業(yè)務(wù)中包含的所有基礎(chǔ)

提供單點的能力，支持中不同業(yè)務(wù)場景的多個能力消費者。由于只提供業(yè)務(wù)場景中的某一小段，對業(yè)務(wù)流程的抽象要求適中，需要一定的

擴(kuò)展機(jī)制 線？多層級復(fù)用在平臺化架構(gòu)中，能力的復(fù)用可分為三個層級：

提供多個連續(xù)或關(guān)聯(lián)的高能力，支持不同業(yè)務(wù)場景的多個能力消費者。對業(yè)務(wù)流程的抽象要求高，由于需要支持不同業(yè)務(wù)模式對同一個業(yè)務(wù)流程的差異化需求，必 須有靈活的擴(kuò)展機(jī)制 其中“業(yè)務(wù)能力復(fù)用”和“業(yè)務(wù)模式復(fù)用”層級都對可復(fù)用能力的識別和設(shè)計提出了要求。因此，基于前面論述的可復(fù)用能力構(gòu)建方法，我們就能實現(xiàn)這兩層的復(fù)用效果。業(yè)務(wù)模式復(fù)用支撐多層級復(fù)用為什么能實現(xiàn)呢？首先在于底層領(lǐng)域模型的設(shè)計，有了建模后的領(lǐng)域?qū)ο筇峁┕蚕淼幕A(chǔ)能力，再加上擴(kuò)展機(jī)制，就能實現(xiàn)基礎(chǔ)能力在不同業(yè)務(wù)上的復(fù)用；而經(jīng)過通用流程的建模，這些基礎(chǔ)業(yè)務(wù)模式復(fù)用支撐支撐

能力又能進(jìn)一步組裝成更大粒度的可復(fù)用能力組件，從而實現(xiàn)局部業(yè)務(wù)流程的復(fù)用；如果業(yè)務(wù)流程的復(fù)用能夠延伸到業(yè)務(wù)的全流程，即對于同一類共性業(yè)務(wù)其全流程都能基于一個解決方案模板定制，而這個解決方案模板是其下所有能力組件和基礎(chǔ)能力的封裝，那么新的業(yè)務(wù)只需定制該解決方案模板即可實現(xiàn)業(yè)務(wù)模式的復(fù)用，快速上線新業(yè)務(wù)。其關(guān)系如下：業(yè)務(wù)流程復(fù)用業(yè)務(wù)流程復(fù)用領(lǐng)域模型復(fù)用能力復(fù)用領(lǐng)域模型復(fù)用能力復(fù)用支撐（圖3.2-18多層級復(fù)用的關(guān)系）復(fù)用基礎(chǔ)能力和能力組件在識別和構(gòu)建了平臺的基礎(chǔ)能力和能力組件之后，不同業(yè)務(wù)就能針對特定的業(yè)務(wù)需求復(fù)用它們并快速定制。方法是對基礎(chǔ)能力下的擴(kuò)展點進(jìn)行擴(kuò)展實現(xiàn)的配置和開發(fā)，示例如下：能力組件創(chuàng)建訂單擴(kuò)展點1 擴(kuò)展點2.[擴(kuò)展點2]和開發(fā)擴(kuò)展實現(xiàn)：校驗商品信息校驗商戶信息校驗用戶信息創(chuàng)建訂單創(chuàng)建訂單校驗商品信息業(yè)務(wù)A的“創(chuàng)建新訂單”校驗用戶信息（圖3.2-19復(fù)用基礎(chǔ)能力和能力組件的示例）復(fù)用基礎(chǔ)能力和能力組件的主要步驟如下：配置新業(yè)務(wù)對應(yīng)的業(yè)務(wù)身份在各基礎(chǔ)能力擴(kuò)展點上的擴(kuò)展實現(xiàn)，如果無需定制可直接采用默認(rèn)擴(kuò)展實現(xiàn)。開發(fā)基礎(chǔ)能力的擴(kuò)展實現(xiàn)。根據(jù)業(yè)務(wù)流程，編排基礎(chǔ)能力和能力組件，實現(xiàn)業(yè)務(wù)需求。對于現(xiàn)有能力不能滿足業(yè)務(wù)需求的情況，需要平臺側(cè)新增開發(fā)任務(wù)，修改或者新增基礎(chǔ)能力

和能力組件；然后應(yīng)用側(cè)按上述過程完成定制使用。復(fù)用解決方案對于新業(yè)務(wù)，如果已構(gòu)建了其所屬共性業(yè)務(wù)的解決方案，則可通過復(fù)用該解決方案進(jìn)行業(yè)務(wù)的快速定制。方法是：基于解決方案的通用流程定制新業(yè)務(wù)流程，并對基礎(chǔ)能力下的擴(kuò)展點進(jìn)行擴(kuò)展實現(xiàn)的配置和開發(fā)。新業(yè)務(wù)A新業(yè)務(wù)A新業(yè)務(wù)全流程能力組件基礎(chǔ)能力XXX基礎(chǔ)能力XXX能力組件基礎(chǔ)能力2XXXXX基礎(chǔ)能力1XXXXX解決方案通用流程復(fù)用&個性化配置 定制開發(fā)解決方案通用流程能力組件能力基礎(chǔ)能力1XX擴(kuò)展點 基礎(chǔ)能力2XX擴(kuò)展點 基礎(chǔ)能力XX擴(kuò)展點 基礎(chǔ)能力XX擴(kuò)展點 XX擴(kuò)展點 XX擴(kuò)展點 XX擴(kuò)展點 XX擴(kuò)展點 XX擴(kuò)展點 XX擴(kuò)展點 XX擴(kuò)展點 XX擴(kuò)展點 （圖3.2-20復(fù)用解決方案快速定制新業(yè)務(wù)）復(fù)用解決方案的主要步驟如下：基于選定的解決方案，配置新業(yè)務(wù)的業(yè)務(wù)全流程。配置新業(yè)務(wù)對應(yīng)的業(yè)務(wù)身份在各基礎(chǔ)能力擴(kuò)展點上的擴(kuò)展實現(xiàn)，如果無需定制可直接采用默認(rèn)擴(kuò)展實現(xiàn)。

開發(fā)基礎(chǔ)能力的擴(kuò)展實現(xiàn)。根據(jù)業(yè)務(wù)全流程，編排基礎(chǔ)能力和能力組件，實現(xiàn)業(yè)務(wù)需求。對于現(xiàn)有能力不能滿足業(yè)務(wù)需求的情況，需要能力組件和解決方案；然后應(yīng)用側(cè)按上述過程完成定制使用。業(yè)務(wù)架構(gòu)元模型補(bǔ)充說明er業(yè)務(wù)流程子域er業(yè)務(wù)流程子域領(lǐng)域?qū)ο箢I(lǐng)域事件服務(wù)業(yè)務(wù)服務(wù)組織組織單元崗位角色業(yè)務(wù)組合管理業(yè)務(wù)群業(yè)務(wù)場景階段活動階段活動任務(wù)步驟規(guī)則業(yè)務(wù)身份擴(kuò)展實現(xiàn)流程 能力通用流程解決方案能力組件可變點基礎(chǔ)能力擴(kuò)展點領(lǐng)域（圖3.1-1業(yè)務(wù)架構(gòu)元模型）業(yè)務(wù)維度此維度主要對企業(yè)的業(yè)務(wù)組合管理進(jìn)行建模，分析企業(yè)各主營業(yè)務(wù)和輔助業(yè)務(wù)的關(guān)系結(jié)構(gòu)及運作模式。要素如下：業(yè)務(wù)業(yè)務(wù)組合管理業(yè)務(wù)群業(yè)務(wù)場景業(yè)務(wù)群：是企業(yè)基于業(yè)務(wù)戰(zhàn)略拆解，確定開展的特ToC其下又進(jìn)一步細(xì)分為快消品業(yè)務(wù)群和消費電子業(yè)務(wù)群等。實體商品業(yè)務(wù)、生活服務(wù)業(yè)務(wù)等；內(nèi)部支撐類的業(yè)務(wù)比如人力資源管理等。場景：是面向用戶提供價值的端到端業(yè)務(wù)場景。通常從4W1H（What、Who、Where、When、How）的維度識別和定義業(yè)務(wù)場景要素，然后從業(yè)務(wù)場景要素的排列組合中篩選出有實際意義的業(yè)務(wù)場景。流程維度此維度主要對企業(yè)的業(yè)務(wù)流程進(jìn)行分層建模，分析企業(yè)如何通過一系列業(yè)務(wù)活動，按照相關(guān)的業(yè)務(wù)規(guī)

則將輸入轉(zhuǎn)換成為有價值的輸出，從而實現(xiàn)用戶價值。要素如下：活動任務(wù)步驟規(guī)則流程階段階段：流程階段活動：即業(yè)務(wù)活動，是某個業(yè)務(wù)角色辦理的業(yè)務(wù)事項，包含一個或一組任務(wù)，有明確的業(yè)務(wù)成果和業(yè)務(wù)輸出。比如：商品發(fā)布、活動發(fā)布等。任務(wù)：是完成活動的工作程序，是流程的基本組成單元。比如：查詢商品詳情、更新商品庫存、創(chuàng)建訂單等。步驟：是完成任務(wù)的具體步驟，是流程的最原子操作。比如：校驗用戶狀態(tài)、校驗商戶狀態(tài)、訂單總價試算等。業(yè)務(wù)規(guī)則：是定義或約束業(yè)務(wù)某些方面的陳述，旨在維護(hù)業(yè)務(wù)結(jié)構(gòu)或控制或影響業(yè)務(wù)行為，它描述業(yè)訂單提貨方式且訂單.組織維度此維度主要對企業(yè)的組織體系進(jìn)行分析。公司組織體系指為了保障戰(zhàn)略和業(yè)務(wù)規(guī)劃落地，以及有效實要素如下：組織組織組織單元崗位角色組織單元：是公司組織體系的組成單元。崗位：是隨組織結(jié)構(gòu)設(shè)定的，要求個體完成的一項或多項責(zé)任以及為此賦予個體的權(quán)力的總和。

角色：是業(yè)務(wù)流程中活動參與者的原型，參與者在流程中的位置通過擔(dān)任合適的角色確定。組織為完成某一目標(biāo)，往往會把此目標(biāo)分解，以便能交給不同能力和責(zé)任的角色合作完成。服務(wù)維度此維度主要對企業(yè)對內(nèi)和對外提供的業(yè)務(wù)服務(wù)進(jìn)行建模分析。要素如下：業(yè)務(wù)服務(wù)：是企業(yè)和企業(yè)的每個業(yè)務(wù)單元為其客戶提供的內(nèi)部和外部服務(wù)。服務(wù)是能力對外呈現(xiàn)價值的方式，是具備明確的業(yè)務(wù)特征，獨立完整、由一提交訂單等。PAGE42PAGE424構(gòu)框架應(yīng)用架構(gòu)的核心關(guān)注點是業(yè)務(wù)需求是由哪些應(yīng)用承載的，它們與用戶是如何交互的，它們之間的關(guān)系以及是如何交互的，它們訪問或變更了什么數(shù)據(jù)。應(yīng)用架構(gòu)的設(shè)計主要以應(yīng)用（Application）的設(shè)計為核心，向外圍可以延伸到平臺型企業(yè)架構(gòu)對于應(yīng)用分層，分組的設(shè)計。例如大家關(guān)注的以微服務(wù)為代表的分布式應(yīng)用架構(gòu)，以及此類架構(gòu)模式下的常見問題，例如微服務(wù)如何劃分如何組織，都是應(yīng)用架構(gòu)在這個粒度需要關(guān)注的問題。同樣，以應(yīng)用為基準(zhǔn)，向內(nèi)部延伸又會涉及到應(yīng)用

內(nèi)部的架構(gòu)設(shè)計。例如常見的應(yīng)用分層設(shè)計，領(lǐng)域驅(qū)動設(shè)計中提到的六邊形架構(gòu)、洋蔥模型，包括領(lǐng)域?qū)ο蟮脑敿?xì)建模與設(shè)計，都是在應(yīng)用架構(gòu)這個粒度需要關(guān)注的問題。而其中的領(lǐng)域?qū)ο笤O(shè)計在業(yè)務(wù)架構(gòu)以及后續(xù)的數(shù)據(jù)架構(gòu)中都會提及，本框架充分融合了企業(yè)架構(gòu)與領(lǐng)域驅(qū)動設(shè)計的思想和方法，從業(yè)務(wù)架構(gòu)到應(yīng)用架構(gòu)以及后續(xù)展開的數(shù)據(jù)架構(gòu)，都秉承以領(lǐng)域?qū)ο笤O(shè)計作為架構(gòu)的核心要素，跨越架構(gòu)邊界，使領(lǐng)域?qū)ο笞鳛橐粭l主線，串聯(lián)起各個架構(gòu)視圖，也有利于保證各類架構(gòu)的連貫和一致性。PAGE44PAGE44應(yīng)用架構(gòu)元模型綜述應(yīng)用架構(gòu)的內(nèi)容元模型包括“端口”、“結(jié)構(gòu)”、“狀態(tài)”三個部分，如下圖所示：IT系統(tǒng)的職責(zé)、邊界建模，其中包括，應(yīng)用組件、應(yīng)用、應(yīng)用組、應(yīng)用層端口部分用來對應(yīng)用的出入口建模，其中包括應(yīng)用服務(wù)和擴(kuò)展點狀態(tài)部分用來對應(yīng)用狀態(tài)的變更建模，其中包括領(lǐng)域?qū)ο蠛筒蛔兞渴褂檬褂脴I(yè)務(wù)流程端口應(yīng)用服務(wù)應(yīng)用層實現(xiàn)結(jié)構(gòu)應(yīng)用組包含多個? 包含多個狀態(tài)不變量識別多個?需要同時變更擴(kuò)展點應(yīng)用組件包含多個?實現(xiàn)技術(shù)服務(wù)使用變更數(shù)據(jù)對象訪問領(lǐng)域?qū)ο髴?yīng)用(圖4.1-1企業(yè)級應(yīng)用架構(gòu)元模型)應(yīng)用架構(gòu)元模型應(yīng)用平臺化趨勢對應(yīng)用架構(gòu)提出的新挑戰(zhàn)IT系統(tǒng)的形態(tài)逐漸從扁平結(jié)組成底部的平臺，而其他應(yīng)用建立在平臺之上。除IT

提升IT系統(tǒng)各組成部分的自治性，使得變更能夠相對獨立的、以小步快跑的方式發(fā)生。因為無論是創(chuàng)新也好，集中管控也好，雖然變化速率不同，但變化始終存在，既然變化不可避免，我們應(yīng)將精力投入到應(yīng)對變化上。在我們的經(jīng)驗中，應(yīng)用邊界劃分不合理會對應(yīng)對變化產(chǎn)生明顯的負(fù)面作用：粒度過大粒度過大 粒度過細(xì)

限界上下文（BoundaryContext）：是業(yè)務(wù)上下文的邊界，在該邊界內(nèi)，當(dāng)我們?nèi)ソ涣髂硞€業(yè)務(wù)概念時，不會產(chǎn)生理解和認(rèn)知上的歧義（二義性），限界上下文是統(tǒng)一語言的重要保證。功能 ?多個團(tuán)隊在同一個物理維度 界內(nèi)，變更計劃和所需源容易沖突，協(xié)作復(fù)雜障困難或耗時

統(tǒng)一語言（UbiquitousLanguage）：是EricEvans在《域驅(qū)動設(shè)計-處理軟件核心中的復(fù)雜性》中使用的術(shù)語，用于構(gòu)建由團(tuán)隊，開發(fā)人員，領(lǐng)域?qū)＜?調(diào) 通用語言、泛在語言。統(tǒng)一語言是在限界上下文中運行 ?受限于物理邊界，無法維度 故障隔離在局部區(qū)域，故障級聯(lián)影響業(yè)務(wù)支撐資源浪費

運維能力要求高信的開銷，反而

建模的，在其中標(biāo)識表達(dá)了業(yè)務(wù)領(lǐng)域的術(shù)語和概念，并且不應(yīng)該有歧義。帶著對于業(yè)務(wù)上下文邊界的理解，使用業(yè)務(wù)、技術(shù) 降低整體性能這些負(fù)面作用會拖慢IT支撐的響應(yīng)力或穩(wěn)定性，因此，“如何劃分IT系統(tǒng)的邊界，以合理的布局更好地應(yīng)對變化”是需要解決的挑戰(zhàn)。在平臺化趨勢之前就已經(jīng)開始流行的微服務(wù)架構(gòu)風(fēng)格的催化下，這個挑戰(zhàn)就已凸顯，而平臺化強(qiáng)調(diào)可復(fù)用的服務(wù)，必然會對原有系統(tǒng)進(jìn)行打散和重組，進(jìn)一步加劇了這個挑戰(zhàn)。如何劃分IT布局更好地應(yīng)對變化從上文的分析可以看出，邊界劃分其實從應(yīng)用架構(gòu)視角出發(fā)，對功能、運行層面變化的應(yīng)對設(shè)計，是應(yīng)用架構(gòu)設(shè)計的重要部分。我們在進(jìn)行應(yīng)用架構(gòu)設(shè)計的過程中，融合了領(lǐng)域驅(qū)動設(shè)計中的限界上下文與統(tǒng)一語言的概念，延續(xù)業(yè)務(wù)架構(gòu)部分中對于領(lǐng)域?qū)ο蟮淖R別和子域劃分，結(jié)合組織與技術(shù)的要素，從多個方面充分考量對于應(yīng)用的建模。

都能理解的統(tǒng)一語言，以兩大階段實現(xiàn)邊界劃分：從功能需求層面出發(fā)，按“單一職責(zé)”原則劃分邏輯邊界加入非功能需求，按架構(gòu)質(zhì)量屬性調(diào)整邏輯邊界并劃分物理邊界這個設(shè)計過程可通過元模型提供的應(yīng)用層、應(yīng)用組、應(yīng)用、應(yīng)用組件進(jìn)行不同層次的邊界劃分建模。應(yīng)用組建模應(yīng)用組是一種大比例結(jié)構(gòu)的邏輯邊界劃分結(jié)構(gòu)，其主要作用是：應(yīng)用組作為一種粗粒度的劃分，幫助我們快速找到進(jìn)一步劃分的切入點我們在與利益干系人對話時，需要一個能夠代表一組相關(guān)物理邊界的結(jié)構(gòu)，以避免不必要的細(xì)節(jié)干擾在結(jié)構(gòu)上，應(yīng)用組包含了多個應(yīng)用（物理邊界）。應(yīng)用組常常對應(yīng)到數(shù)字化產(chǎn)品級別，例如CRM系統(tǒng)（客戶關(guān)系管理系統(tǒng)，其下可能包括客戶檔案管理應(yīng)用、客戶忠誠度管理應(yīng)用）；在業(yè)界流行的按中心劃分的中臺/平臺架構(gòu)里，應(yīng)用組常常對應(yīng)到某個中心。應(yīng)用組的建模依據(jù)主要來自于業(yè)務(wù)架構(gòu)的業(yè)務(wù)、組織兩部分成果的輸入。在從0到1的應(yīng)用架構(gòu)設(shè)計場景里，這個步驟不求精確，主要是幫助我們建立劃分的起點。例如：汽車行業(yè)的經(jīng)銷商，會同時開展新車銷售和售后服務(wù)兩個不同的業(yè)務(wù)，在經(jīng)銷商內(nèi)部一般也由不同的組織負(fù)責(zé)。按職責(zé)類型分解，應(yīng)用組件可分為四種常見的參考類型：

而維修保養(yǎng)和配件銷售又是售后服務(wù)中的兩個不同業(yè)務(wù)場景。我們可依此快速建立一個兩級的應(yīng)用組，這個結(jié)構(gòu)并不精確，但足夠我們進(jìn)行下一步工作。應(yīng)用組件建模應(yīng)用組件是一種細(xì)粒度的應(yīng)用邏輯邊界劃分結(jié)構(gòu)，是對功能、數(shù)據(jù)的封裝。向上，一個或多個應(yīng)用組件可組成一個應(yīng)用（物理邊界），向下，就是代碼實現(xiàn)層面的結(jié)構(gòu)設(shè)計了。因此，應(yīng)用組件是架構(gòu)層面運用“單一職責(zé)”原則的最小單元。類型功能類型功能數(shù)據(jù)例子變化原因流轉(zhuǎn)類支撐某個流程或流程中的一段活動流程的狀態(tài)流轉(zhuǎn)信息和決策證據(jù)結(jié)賬組件，其支撐的流數(shù)據(jù)是訂單流程編排變化規(guī)格類支撐某個業(yè)務(wù)規(guī)則，給出專業(yè)意見一般不管理數(shù)據(jù)的生命周期，只負(fù)責(zé)加工給出結(jié)果驗證：如發(fā)票是否逾期業(yè)務(wù)規(guī)則的計算邏輯變化視圖類支撐某個業(yè)務(wù)活動所需的整合信息一般不管理數(shù)據(jù)的生命周期，只負(fù)責(zé)加工給出商品信息的整合展示視圖組裝邏輯變化配置類為前三類提供配置輸入基礎(chǔ)的資源信息商品目錄設(shè)置內(nèi)容管理系統(tǒng)中的配置功能規(guī)則前三類對配置要求的變化篩選：三月內(nèi)消費過計算：計價、導(dǎo)航路結(jié)果 ?統(tǒng)計報表的開關(guān)再延伸至規(guī)格類、視圖類，最后再識別配置類。建業(yè)務(wù)規(guī)則。其過程可總結(jié)為三個子步驟：子步驟一：功能和數(shù)據(jù)識別逐層分解業(yè)務(wù)流程，從活動、任務(wù)、步驟中可以得到相對細(xì)粒度的業(yè)務(wù)需求，即IT系統(tǒng)需要提供的功能；將業(yè)務(wù)對象轉(zhuǎn)化為不同類型的數(shù)據(jù)對象。子步驟二：功能與數(shù)據(jù)關(guān)聯(lián)，識別應(yīng)用組件按不同組件類型將功能與數(shù)據(jù)對象關(guān)聯(lián)對應(yīng)，得出應(yīng)用組件。在流轉(zhuǎn)類組件建模時，有兩個關(guān)注點需要特別注意：

一是隱式業(yè)務(wù)邊界的識別。在對業(yè)務(wù)流程分析時，地點、角色變化時，我們面對的業(yè)務(wù)干系人和他們的工作環(huán)境不同，其關(guān)注點可能不同，這往往會成這可以幫助我們細(xì)分?jǐn)?shù)據(jù)對象和應(yīng)用組件，例如：線上訂餐流程中，客戶提交訂單并完成付款后，訂單會被派單至廚房備餐。即使在業(yè)務(wù)架構(gòu)的產(chǎn)出中沒有識別出客戶訂單和廚房備餐單據(jù)可能是不同的業(yè)務(wù)對象，也可以從地點和角色的變化將訂餐結(jié)賬、備餐識別為不同的應(yīng)用組件二是數(shù)據(jù)對象變更一致性約束的識別。在流轉(zhuǎn)類應(yīng)用組件的建模過程中，應(yīng)該盡可能識別業(yè)務(wù)規(guī)則中不變量要保護(hù)的不變量要保護(hù)的兩個數(shù)據(jù)對象，分別由兩個組件各自管理，這可能說明應(yīng)用組件的粒度過細(xì)，在后續(xù)劃分物理邊界時，容易出現(xiàn)事務(wù)邊界被破壞的情況保障?必須同時變更保障?必須同時變更致保障?必須同時變更致<<采購<<采購申請>>實現(xiàn)變更>>實現(xiàn)購單行組變更購單>sum(采購單行.金額)<<采購申請>>實現(xiàn)件>>變更>>購單>變量”建模。不變量代表了哪些數(shù)據(jù)對象需要被同時改變，我們可以依此復(fù)查，是否將應(yīng)用組件拆分得太細(xì)，破壞了事務(wù)邊界。子步驟三：識別、調(diào)整各應(yīng)用組件之間的依賴關(guān)系識別各組件間的依賴關(guān)系，在這里盡可能避免兩種依賴：一是盡可能避免依賴容易變化的組件。盡管可以定義契約，但容易變化的組件容易打破先前定義的契約。二是盡可能避免出現(xiàn)雙向依賴。雙向依賴往往對可適配性產(chǎn)生負(fù)面影響，可通過引入第三個組件或擴(kuò)展點（詳見“應(yīng)用服務(wù)與擴(kuò)展點”）解耦。<<應(yīng)用組件>結(jié)賬 生成支付請求 雙向依賴變更訂單結(jié)余<<應(yīng)用組件>><<應(yīng)<<應(yīng)結(jié)賬件>>生成支付請求 <<應(yīng)支付件>>變更訂單結(jié)余單向依賴 實現(xiàn) 提供>>>>(圖4.2-3通過擴(kuò)展點將雙向依賴轉(zhuǎn)換為單向依賴)

應(yīng)用建模有了應(yīng)用組件作為“原料”，應(yīng)用架構(gòu)的物理邊界設(shè)計就有了輸入，下一步的目標(biāo)是識別是否存在架構(gòu)質(zhì)量屬性沖突，作為應(yīng)用建模的重要參考，調(diào)整邏輯邊界，并確定物理邊界。質(zhì)量屬性沖突包括：該邊界內(nèi)是否存在變更頻率沖突我們傾向于將高頻變更的應(yīng)用組件與其他應(yīng)用組件阻隔開。物理邊界意味著部署的獨立性，不容易產(chǎn)生發(fā)布計劃、部署所需資源上的沖突。如果一個功能擴(kuò)展帶來的變更，集中在某個應(yīng)用、甚至應(yīng)用組件內(nèi)，其協(xié)作成本相對更低。該邊界內(nèi)是否有特別的移植性要求該要求指應(yīng)用遷移到不同組織、業(yè)務(wù)運作方式的能力，或者換一個角度來說是應(yīng)用承接新業(yè)務(wù)模式的能力，這恰巧是平臺所需要的關(guān)鍵能力。在實現(xiàn)某一個業(yè)務(wù)模式時，必然存在該業(yè)務(wù)模式的特定需求和可以支持多個業(yè)務(wù)模式的公共需求。我們傾向于將特定需求和公共需求的實現(xiàn)隔離到不同的應(yīng)用組件、甚至應(yīng)用里。以便新業(yè)務(wù)模式入住時，方便實現(xiàn)功能擴(kuò)展以及實現(xiàn)部署要求。該邊界內(nèi)是否有特別的彈性要求該要求指應(yīng)用是否容易通過調(diào)整容量來應(yīng)對流量變化。在這里應(yīng)用的粒度決定了容量調(diào)整的難度和成本。因為應(yīng)用的粒度太大，而流量變化只影響其中某個應(yīng)用組件，則擴(kuò)容帶來了不必要的成本浪費。另一種情況是某個應(yīng)用組件不能調(diào)整容量或者非常困難，這主要是因為其依賴于某個無法擴(kuò)展的技術(shù)組件。例如，某應(yīng)用組件依賴硬件加密設(shè)備（技術(shù)組件）對報文進(jìn)行加密，擴(kuò)容意味著需要采買硬件加密設(shè)備。因此，需要將這類應(yīng)用組件隔離開，使其他組件更容易應(yīng)對彈性要求。該邊界內(nèi)是否有特別的性能要求該要求與彈性要求類似，將不同性能要求（請求處理的快慢程度）的應(yīng)用組件分開，特別是對于特定問題，可能適合某個技術(shù)棧，但出于整體建設(shè)、運維成本考慮并適合大面積使用，我們傾向于將其設(shè)計為一個獨立的應(yīng)用，與其他應(yīng)用組件隔離開，使得異構(gòu)。典型的例子是，部分高性能場景適合用C語言實現(xiàn)。該邊界內(nèi)是否有特別的可用性要求該要求與彈性要求類似，將不同可用性要求的應(yīng)用例如，如果某個應(yīng)用組件支撐的功能尚處在業(yè)務(wù)探索階段，那么可以適當(dāng)降低其可用性要求，這要求將其與承擔(dān)核心功能的應(yīng)用組件隔開?；蚴钱?dāng)故障發(fā)生時，能否將故障隔離在局部范圍，減少應(yīng)用失效造成的業(yè)務(wù)損失。該邊界內(nèi)是否有特別的信息安全要求例如，某應(yīng)用組件需要保管信用卡持卡人信息，為降低該信息被非授權(quán)訪問的風(fēng)險，我們傾向于將該應(yīng)用組件與其他應(yīng)用組件拆開，將其獨立部署在一個加固的運行環(huán)境中。

該邊界內(nèi)是否有特別的合規(guī)要求有時邊界劃分會受到法律、法規(guī)或行業(yè)規(guī)定的影響。例如某業(yè)務(wù)是需要公證的抽獎活動，按照當(dāng)?shù)匦袠I(yè)要求，中獎人抽取的實現(xiàn)需要通過公證處認(rèn)證。我們傾向于由已通過認(rèn)證的外部應(yīng)用服務(wù)來提供該職責(zé)，或是將該職責(zé)獨立劃分為一個應(yīng)用，減少認(rèn)證需要花費的時間?；谝陨蠜_突的進(jìn)行邏輯邊界調(diào)整，將由特別要求的應(yīng)用組件獨立劃分到各自的物理邊界，剩余的應(yīng)用組件原則上保留在一個物理邊界，以元模型中的“應(yīng)用”表述該劃分結(jié)果。應(yīng)用層建模除了應(yīng)用組之外，常見的一種大比例結(jié)構(gòu)是分層，因此我們也將應(yīng)用層作為一種元素加入進(jìn)來。我們認(rèn)為分層代表了企業(yè)對變化速率的認(rèn)知，并為不同的變化速率匹配架構(gòu)設(shè)計目標(biāo)和管理方法。并不是所有的IT系統(tǒng)都需要“最高配”的架構(gòu)屬性，實現(xiàn)成本也是重要的約束條件。一個處在業(yè)務(wù)探索期的信息體統(tǒng)，其生命周期一般只有6-12個月，且變化劇烈。為其達(dá)成過高的架構(gòu)屬性顯然是不具備投資合理性的。另一方面，平臺化架構(gòu)中作為支撐層的IT系統(tǒng)在架構(gòu)屬性上需要更多重視和投入。我們常?？吹狡髽I(yè)僅僅在全景圖紙上做了分層，但缺少架構(gòu)設(shè)計、治理中的實際舉措，功能上的變更往往會擊穿多層，支撐層團(tuán)隊疲于奔命。例如:企業(yè)有多條業(yè)務(wù)線，各自有不同商品結(jié)構(gòu)，原各設(shè)置一個前臺團(tuán)隊負(fù)責(zé)其應(yīng)用的交付和運營。為降低成本，決定將各業(yè)務(wù)線的商品展示、搜索等需求集中起來，設(shè)立商品中心作為平臺支撐層的應(yīng)用/應(yīng)用組?！皬?fù)刻”各業(yè)務(wù)線的商品結(jié)構(gòu)，而未作相應(yīng)設(shè)計的話，面對多條業(yè)務(wù)線的多線需求，往往不堪重負(fù)，成為瓶頸。因此商品中心必須設(shè)計一個商品結(jié)構(gòu)的元模型，可通過運營人員組裝的方式，為不同業(yè)務(wù)線的商品結(jié)構(gòu)建模。這樣才能將前臺各業(yè)務(wù)線的商品展示、搜索需求變化就地消化。因此，如果對分層做出設(shè)計，那么在職責(zé)劃分上就要做出應(yīng)對，否則分層容易成為空中樓閣。應(yīng)用服務(wù)與擴(kuò)展點建模元模型中的應(yīng)用服務(wù)最主要的作用是顯式地向?qū)ν舛x一個契約。這在做應(yīng)用組件升級/替換、定義IT服務(wù)級別等架構(gòu)治理場景中會有幫助。應(yīng)用服務(wù)在線上訂餐流程中，用戶需要IT系統(tǒng)支持提交訂單、發(fā)起付款、訂單狀態(tài)查看、取消訂

單四個行為，可將它們建模為應(yīng)用服務(wù)――訂餐結(jié)賬應(yīng)用服務(wù)的來源可以是“自動化”的業(yè)務(wù)服務(wù)，如果在業(yè)務(wù)架構(gòu)采用了“能力建?！保ㄒ?.2.3.4能力建模）也可以直接將其構(gòu)建塊轉(zhuǎn)換過來：“能力組件”轉(zhuǎn)換為“應(yīng)用服務(wù)”“基礎(chǔ)能力”轉(zhuǎn)換為“功能”另一方面，如果說應(yīng)用服務(wù)顯式定義了應(yīng)用組件的入口，那么擴(kuò)展點則顯式定義了應(yīng)用組件的出口。擴(kuò)展點有兩個作用：一是反轉(zhuǎn)對不穩(wěn)定應(yīng)用組件的依賴，降低其變化對自身的沖擊，這在“應(yīng)用組件建模”一節(jié)中有提到。二是增強(qiáng)可移植性質(zhì)量屬性，即不同的業(yè)務(wù)場景下對于同一個應(yīng)用組件的邏輯存在差異化需求，對業(yè)務(wù)架構(gòu)的“變化點”，根據(jù)當(dāng)前應(yīng)用狀態(tài)上下文中的業(yè)務(wù)身份，針對性選擇適合的邏輯實現(xiàn)。例如：某公司有零售門店，銷售零售商品，同時在店內(nèi)還有餐廳，我們可以將客戶結(jié)賬識別為一個可共享服務(wù)。結(jié)賬后，商品訂單需要派單至倉庫提貨，而餐廳訂單需要派單至廚房這個擴(kuò)展點，并找到兩種業(yè)務(wù)模式的擴(kuò)展實現(xiàn)關(guān)系。>>使用使用<<商品結(jié)賬>>實現(xiàn)/提供<<商品訂單>>使用使用使用<<餐廳結(jié)賬>>實現(xiàn)/提供<<餐廳訂單>>使用>>履 <<應(yīng)結(jié)賬務(wù)>>實現(xiàn)/提供實現(xiàn) 實現(xiàn)當(dāng)付款后訂單放行的擴(kuò)展點>>