阿里妹導讀
作者總結(jié)這些年在支付寶做架構(gòu)的經(jīng)驗，把自己摸索成長的內(nèi)容寫下來，從對架構(gòu)師的認知到業(yè)務能力和架構(gòu)能力多方面總結(jié)了案例經(jīng)驗，希望可以幫助到大家。
在內(nèi)網(wǎng)上有太多的架構(gòu)相關的文章了(比如大名鼎鼎的自頂向下)，我之前也寫過應用架構(gòu)設計的經(jīng)驗。但是總有種霧里看花的感覺，好像有很多相關的知識，soa、分布式事務、DDD、復雜系統(tǒng)重構(gòu)、領域建模、業(yè)務架構(gòu)、等等等，這些復雜的名詞和知識感覺學了一堆仍然不得其法。
所以我準備把我這些年在支付寶做架構(gòu)，自己摸索成長的內(nèi)容寫下來，看能否幫助到大家。
成長，是認知的升級
我們經(jīng)常說，要有架構(gòu)師的能力，或者說需要成長為一個架構(gòu)師。但是我們需要怎么成長？或者說什么才是“能力”？架構(gòu)師的能力包含了什么內(nèi)容？在我看來，能力的本質(zhì)就是認知。所以，所謂架構(gòu)師就是有著架構(gòu)師的認知，和一些通用技術能力。
為什么
在我的認知里（哈哈，這句話也說明了這個標題的重要性），所謂能力，就是不同的認知能力。所謂成長，就是認知升級的一個過程。我想先用一個例子，來說明這個事情。我在面試中經(jīng)常被問到一個問題，我也喜歡問別人：JAVA當中如何處理多線程，如何處理并發(fā)。
高級工程師的回答：
使用Thread對象的方式來開啟線程，傳遞Runnable，在多線程里面處理業(yè)務代碼，這樣就是并行處理了。此外在jdk1.5里面，增加了Executors類，可以方便的使用一些ThreadPool來處理多線程的線層復用部分。并發(fā)安全部分，如果多線程訪問共享資源，那么就會有線程安全問題。我們可以使用sync關鍵字來同步代碼。jdk1.5之后是Lock可以處理。這里可以擴展出很多的問題，比如Lock的實現(xiàn)原理，sync基于對象頭，局部變量沒有線程安全問題（線程棧）等等的擴展問題。
但是這樣回答有問題嗎？沒有問題，不過沒回答完。
我的回答：
不用多線程。這是我真實的回答，同時我99%以上的場景都拿到了正反饋。即：面試官非常認可我的回答。具體這個問題我怎么回答，我接來下講，什么是架構(gòu)師的認知就會說到。
這里，我想通過這個例子說明的就是：能力的不同，對于這個問題的認識就不同。反過來說也一樣，對這個問題的認識的不同，也代表的能力的不同。而這，就是為什么我覺得成長，是認知的升級。所謂認：就是我們對事務的認識，理解，歸因和定義。所謂知：就是我們要做的事情的方法，方案，選擇和決策。
是什么
那么架構(gòu)師，需要的認知是什么呢？我從阿里的job model里面抽離出來關鍵字：系統(tǒng)性&體系化思考，知其然知其所以然。仍然用上面的問題：java當中如何使用多線程？如何處理線程安全問題？
我的回答：不用多線程。
為什么？
從一些危害講，業(yè)務系統(tǒng)處理業(yè)務請求，如果使用多線程模型并且使用了sync，非常容易導致請求hang死，并且不利于我們的并發(fā)。
從線程技術上來說，默認是unbound。這會導致很多的內(nèi)存溢出，并且使用多線程，服務器重啟會導致業(yè)務處于不可知的狀態(tài)。
從使用原因來說：業(yè)務中使用多線程（有別于Tomcat這種容器中間件）是為了提高并發(fā)能力，或者是異步化業(yè)務能力。而這兩種都有其他的方案來替代。比如高并發(fā)，我們可能會進行一些拆分操作，比如異步化，會使用消息隊列等。
怎么做呢，比如異步化，我們用消息隊列。如果是資源共享，那么盡量做到讀，而不是寫。如果是共享寫，那么根據(jù)業(yè)務場景盡量拆分，然后歸攏業(yè)務職責。這也是架構(gòu)設計中聚合的重要性。很多框架比?.NETty，都有無鎖設計。
我上面簡單的說了一下。正常業(yè)務中是不會用線程池的。
這體現(xiàn)了哪些方面呢。
體系化
比如我在回答這個問題的時候，很隨意的拆分成了幾個維度來回答：壞處，技術難點，使用場景，最佳實踐。這就是當我們回答一個問題的時候，自然而然的按照一定的模型思考，然后進行回答。無論這個模型是什么，他都是體系化的一種。
比如直接回答：1.為什么要用多線程？2.不用多線程有沒有別的方案等等，這些都是思考的一個模型，按照這些維度進行拆分，這些維度進行匯總。就是體系化。
很有趣，讀到這里又可以停下來了。我們可以回答：如何拿到架構(gòu)師offer？
我們能否做到一個維度拆分？比如我這個文章，就是一個拆分的維度。而開始思考維度，就是架構(gòu)師需要的一個認知，這也是體系化&系統(tǒng)化思考的表現(xiàn)。關鍵不在于結(jié)構(gòu)是什么，關鍵在于需要有結(jié)構(gòu)。
知其然知其所以然
為什么體現(xiàn)了這個呢，其實很簡單，就是一個能力：多問一個why。這個能力是極其重要的，往往我們對于問題的定義高度，就決定了我們的架構(gòu)高度。比如剛才的例子：如何處理線程安全問題？多問一個why：為什么要處理線程安全問題？可能這個時候就發(fā)現(xiàn)：是因為多線程并發(fā)訪問共享資源問題。
那么我們的方案是不是就可以變成：不訪問，主要是不寫入共享資源，是不是就沒有線程安全問題了？此外，也可以問：為什么要用多線程？可能回答是：要處理多任務并行能力，或者任務異步化能力降低請求耗時問題。那么是不是有別的技術方案可以解決？消息隊列。可靠消息異步化能力。這點非常非常非常重要，重要到應該形成我們的本能。甚至不僅僅是技術方面。比如我這個文章，就可以問，為什么是兩部分。為什么是架構(gòu)師。等等。技術上，任何一個框架，都要問，這個框架解決了什么問題。
怎么做
可以從認知結(jié)構(gòu)上和行為習慣上來說我們怎么做到成長。也可以直接給出答案，我們應該做什么具體的事情。我還是從這兩個維度來描述這個問題。有沒有發(fā)現(xiàn)，我說的內(nèi)容都是總分結(jié)構(gòu)？其實這是非常常用的一個方式。
認知結(jié)構(gòu)
怎么做很簡單，就是要多想一點，要知道用什么方法多想一點，多思考一點。而這個方法就是怎么做，思考出來的過程，就是認知結(jié)構(gòu)，做到了這點，就會很快的成長。
我會簡單的解釋一些分析方法。
首先金字塔模型里面說的一個：MECE原則
總結(jié)來說就是兩個維度：無重復，無遺漏我們描述一個問題或者事情，應該做到不重復。比如我們說什么是人類，可以說兩個維度：生理性別男，生理性別女。這兩個維度是不重復的（這里不討論假定性別問題）。并且是不遺漏的。如果我們劃分是：少年，青年，老年，這就不是一個很好的維度，因為年齡可能存在交叉。
5w2h這個維度思考
5w其實就可以劃分成：
2w（分析維度）：why what?；卮?為什么 和 是什么這個問題。
3w（屬性維度）：when who where
1h ：how to do 核心本質(zhì)怎么做
1h ：how much 核心成本，也是ROI。決策的核心維度，投入產(chǎn)出比。（這個非常核心，沒有最好的架構(gòu)，只有最合適的架構(gòu)）
我講解5w2h的這個過程，就是自然而然的對5w2h進行維度拆分的過程：分析維度，屬性維度，關鍵方案，關鍵ROI。我不斷的重復這個事情，就是想讓大家理解，這些維度都是一個個的方法。我們要形成自己拆維度的習慣。
3why方法
很簡單，對于任何問題，我們追問3個為什么。這樣就能定義問題的本質(zhì)，直面我們具體要解決什么問題。比如：
我們?yōu)槭裁匆@得架構(gòu)師offer？可能是我們想獲得成長和一個好工資。（這里就明白我們本質(zhì)需要，我們是看重工資還是真的成長空間？如果是成長，可能是找到幾個良師益友，也不一定是換公司）
我們?yōu)槭裁匆@得一個好工資？可能是想有更好的生活。（這里就會發(fā)現(xiàn)，其實我們還是回到了生活本質(zhì)，可能會引入wlb這個問題，可能架構(gòu)師就不是這么重要了）
什么是更好的生活？可能是自我價值的體現(xiàn)。（這里可能就會更好的認識自己，所以認知的升級，也是不斷加深自我認知的一個過程）
還有很多很多，比如swot，四象限等等。關鍵是幫助大家打開一個門。這個門就是：我們要多想想，并且我們是要按照一定的方法多想想。
具體的事情
這里我都會在后面詳細的解釋。對于我們技術人員來說。在日常工作和學習中，可以做下面幾個事情。
1.抽象
我感覺這也是架構(gòu)的基礎，哪怕從架構(gòu)的第一階段：框架，開始，都是解決某一類的特定問題。比如ORM框架解決db和java代碼之間的映射關系等問題。
在我們的實際業(yè)務代碼中，我們盡量能對我們要實現(xiàn)的功能，多問一個why，也就是多抽象一點。比如一個活動參與次數(shù)的功能，我們抽象定義成一個通用的計次服務。這樣可以多業(yè)務場景復用。比如我們處理業(yè)務報錯之后的特殊邏輯，可以用AOP+異常處理流程。來做一個通用的框架，可以解決所有分支鏈路和主業(yè)務鏈路的解耦問題。
2.分層定義
按照清晰的維度，進行明顯的層次劃分。不同的層次有不同的特性和符合這一層次的關鍵職責。
在具體的工作中，有個習慣大家可以試試：我們總歸有一層設計，是沒有業(yè)務語義概念的。比如完整的一個insert操作。這個insert sql肯定沒有業(yè)務語義，完全不理解這是一個什么場景需要insert。它只專注于實現(xiàn)insert功能。按照這種方法。我們就可以不斷的抽象出不同的功能。在具體的架構(gòu)方法里面我會介紹的詳細一些。
3.思考業(yè)務問題，業(yè)務本質(zhì)與業(yè)務價值
要思考我們?yōu)槭裁磳懘a，是實現(xiàn)某個功能，這個功能最終怎么產(chǎn)生的業(yè)務價值，那么對我們的功能就有什么要求？對我們代碼的抽象，是架構(gòu)，對業(yè)務本質(zhì)的抽象，也是架構(gòu)。業(yè)務價值最終決定著我們的架構(gòu)價值。
業(yè)務能力
從我們技術角度，業(yè)務就是我們要解決的”問題“。因為對于業(yè)務的定義，公司層面上就是要做”賺錢的事情“。而技術同學，代碼怎么產(chǎn)生價值，就是代碼怎么賺錢，所以描述業(yè)務能力，就是描述我們的定義問題能力。
業(yè)務=賺錢的問題
代碼=怎么賺錢的問題
業(yè)務就等于，代碼上要解決的問題。
必須說明，在公司內(nèi)部晉升和外部面試，最大的不同就在于”業(yè)務“描述上。因為公司更考察業(yè)務洞察能力和業(yè)務本質(zhì)定義的專業(yè)能力。而外部公司，往往不會直接做相關的業(yè)務，只會做相關內(nèi)容，所以考察的往往是”通用的“，并且是”成熟的“特定內(nèi)容解決方案。比如資金類業(yè)務，電商類業(yè)務，創(chuàng)新類業(yè)務，toC個人類業(yè)務這些業(yè)務場景中遇到的技術問題。要想說清楚技術方案，就必須介紹業(yè)務背景。而這就是體現(xiàn)技術專業(yè)度的地方。還有一部分是為了引出架構(gòu)問題，描述我們的架構(gòu)解決了什么業(yè)務問題，就需要對業(yè)務背景，業(yè)務本質(zhì)，業(yè)務問題進行高度抽象的總結(jié)。這也是業(yè)務能力。
業(yè)務背景
是對我們系統(tǒng)的高度總結(jié)，在后續(xù)的面試準備里面我會好好的描述如何結(jié)構(gòu)化的講述我們的業(yè)務背景問題。
這里的業(yè)務背景是從我們系統(tǒng)要處理的核心功能角度出發(fā)來描述的。比如：一個電商公司，一定會分交易領域，匯金領域，商家領域，商品領域。每部分就是核心對要做的內(nèi)容來描述。比如交易領域是圍繞一筆電商交易單據(jù)的狀態(tài)流轉(zhuǎn)的串聯(lián)。支付領域是面向用戶支付資產(chǎn)轉(zhuǎn)移等等。這些簡單的解釋一下核心職責。核心職責也一定會和架構(gòu)核心定位相關。
業(yè)務問題
我一直覺得，架構(gòu)最終目標還是解決問題的。否則沒有”架構(gòu)“這個概念的。如果只寫一個hello word那不會有這些問題。所以要正確的認識和描述，我們的業(yè)務具體發(fā)生了什么變化，我們的業(yè)務邊界是否發(fā)生了擴展，我們是否增加了一些業(yè)務場景。而這些變化，對我們的系統(tǒng)造成了什么問題，我們怎么進行解決的。就體現(xiàn)了我們的架構(gòu)能力。
業(yè)務發(fā)展判斷(前瞻性)
首先，前瞻性以及基于前瞻性判斷的架構(gòu)設計，一定是可考察的?？煽疾炀鸵馕吨欢ㄊ怯蟹椒ǖ?。是有“套路的”。否則根本沒辦法做出一個面向未來的架構(gòu)，只能憑運氣或者架構(gòu)演進&維持。另外，需要大家明白一個事情：業(yè)務sense，業(yè)務前瞻性，最終還是要為架構(gòu)服務的（或許后面的戰(zhàn)略思維是不一樣的）。我從下到上分幾個方面來說：
架構(gòu)演進，擴展性
這是框架和架構(gòu)設計部分。這么多年了spring的IOC本質(zhì)發(fā)生變化了嗎？沒有。為什么？
因為是基于我們核心架構(gòu)定位（DI，控制翻轉(zhuǎn)等）出發(fā)來定義的。這樣本質(zhì)不變，主體結(jié)構(gòu)就不變，發(fā)展就是橫向以及縱向發(fā)展的。
橫向：會有更多的平臺產(chǎn)品，業(yè)務場景出現(xiàn)，但是關聯(lián)關系不變。
縱向：會有更多的前后功能延伸出現(xiàn)，但是本質(zhì)不變（比如spring做了很多的cloud）
網(wǎng)狀：關系變化，所以我們建議把“獨立”作為核心架構(gòu)原子概念，這樣關系就是另外的一個概念（半文鏈接理論）。
這樣整體框架和核心架構(gòu)定位上，是不會發(fā)生變化的。
業(yè)務演進
業(yè)務演進，一定還是符合互聯(lián)網(wǎng)擴展形式的。如果我們不是做商業(yè)模式的擴展。那么一定是原有商業(yè)模式的商業(yè)效率擴展。比如，淘寶并沒有更改交易的本質(zhì)，營銷也是類似于傳統(tǒng)的吆喝。場地費其實就是地皮尋租的概念。
架構(gòu)師往往沒有到戰(zhàn)略視角和洞察的階段，我們需要的是在特定的業(yè)務領域下，判斷未來的發(fā)展方式。所以就擴展就行，抽象定義好業(yè)務的本質(zhì)，然后結(jié)合業(yè)務發(fā)展階段進行擴展。比如我之前做的結(jié)算架構(gòu)，就可以按照橫向擴展演進的方式來進行。
為什么？
因為“結(jié)算”的概念和商業(yè)資金鏈路，很早就有了。支付寶也只是把這些內(nèi)容搬到線上，然后搬到我們的收單支付配套上。所以圍繞商家，供應鏈，供貨商，資金分賬，資金鏈路管理關系，就一定是未來的架構(gòu)演進方向。因為現(xiàn)實社會中，別的企業(yè)用OA或者ERP這樣的系統(tǒng)就在做這個事情。那么沒道理支付寶內(nèi)部的結(jié)算域會有根本的變化。
這里其實有個抽象，類比的一個方法，依賴我們的視野。比如我們做一個社區(qū)架構(gòu)或者業(yè)務方向判斷。
整個互聯(lián)網(wǎng)社區(qū)，從最早的BBS-天涯-貼吧-校內(nèi)-微博-知乎-抖音-小紅書。等等?？梢猿橄蠖x出來不同的模式和不同的內(nèi)容載體（視頻，文字，圖片）。然后傳播從以前的單點-廣播-網(wǎng)狀-核心KOL。但是想想，和最早以前人們下班了之后，搬起來小板凳村口嘮嗑。沒什么本質(zhì)的區(qū)別。業(yè)務演進部分，最終就是回歸到:架構(gòu)延續(xù)這個命題上的。
基于上面我的解釋，其實就有很好的一個方法來做：架構(gòu)定位（隱喻）或者說明燈這個方法。因為業(yè)務本質(zhì)是不會發(fā)生變化的，所以我們圍繞架構(gòu)定位設定的核心領域模型，就不會發(fā)生根本的變化。除非我們的領域發(fā)生變化了
架構(gòu)能力（設計）
這里主要講在設計部分體現(xiàn)的能力，如果一個架構(gòu)師在面試過程中最重要的地方，我覺得就是技術性。而這個技術性，就是我們用技術方案來解決架構(gòu)問題的一種描述。
架構(gòu)能力，展開說我可以說幾十篇文章。所以我直接給一個設計方法論。相信通過我上面對于認知的描述，大家也理解什么叫方法論。
下面是我之前做的一個架構(gòu)方案的目錄。我覺得目錄就很好的體現(xiàn)了方法這個詞，因為無論什么架構(gòu)方案。都可以按照一定的目錄結(jié)構(gòu)來寫。
方法論
我這里說的方法論，就是我們做一個系統(tǒng)的架構(gòu)方案需要經(jīng)過的一些步驟，我們具體的產(chǎn)出物。無論是什么架構(gòu)，都可以按照一定的結(jié)構(gòu)和維度進行分析和拆分，這種通用的方法，就是方法論部分。
方法論+業(yè)務能力，就是某個領域，某個功能架構(gòu)能力的體現(xiàn)。
我這里介紹我的常用方法：架構(gòu)定位（隱喻），業(yè)務架構(gòu)，應用架構(gòu)。
我所做的所有架構(gòu)工作，基本都是上面的三個事情。每一部分都有具體的產(chǎn)出，結(jié)合不同的業(yè)務場景我們都要運用不同的方法。但是就像我在認知里面說的一樣，架構(gòu)的工作也應該是分維度和步驟的。
下面我詳細的介紹每一部分。
架構(gòu)定位
架構(gòu)定位是核心架構(gòu)職責，架構(gòu)上下邊界的高度抽象定義。用一種大家都覺得”理應如此“的方式來提出。和業(yè)務概念高度相似。不同的是架構(gòu)定位還包括功能部分。比如：
交易系統(tǒng)：圍繞一筆商品交易的單據(jù)，進行不同狀態(tài)的流轉(zhuǎn)和業(yè)務參與者關系的流程組裝與驅(qū)動。
支付系統(tǒng)：基于用戶有價資產(chǎn)償付。
商品系統(tǒng)：圍繞商業(yè)活動中，對于物的屬性定義與管控。
賬務核心：圍繞資產(chǎn)管理與資產(chǎn)流轉(zhuǎn)驅(qū)動。
等等，我舉的例子不一定對，但是大家都會覺得有一點道理，有一點抽象，描述了是什么和做什么。如果感覺對，又不對，那么我們的架構(gòu)定位可能就設定對了。
此外，我還想介紹一下我的一個理論：架構(gòu)隱喻
我把這種方法叫做明燈。明燈不是方向，不是目標，不是我們的實施路徑。但是就像黑暗之中的瑩瑩燈火，指明了我們的方向，照亮了我們的目標，牽引著我們的道路。這種”牽引“就是明燈所帶來的核心結(jié)果，他解決了我們的架構(gòu)分層問題，平臺產(chǎn)品問題，架構(gòu)延續(xù)問題。而xp：極限編程，這本書里面的：架構(gòu)隱喻。我感覺就是明燈的一種具象化。用一種具象的概念讓大家理解我們架構(gòu)的”感覺“。比如：我們都知道什么是電商里面的交易。那么架構(gòu)隱喻就可以是：一手交錢，一手交貨。
架構(gòu)定位的作用是巨大的。它指引著我們進行架構(gòu)方案的設計，也幫助我們做架構(gòu)協(xié)同，架構(gòu)宣講，架構(gòu)延續(xù)等等內(nèi)容。同時在一些具象化的內(nèi)容也直接幫助著我們，比如核心平臺產(chǎn)品是不可能超過架構(gòu)定位的。在很多非常復雜的架構(gòu)方案里面，對架構(gòu)定位可能就討論一個多月。同時，如果沒有進行這一步，架構(gòu)方案在進行到某個程度的時候也一定會失敗。比如有的域進行架構(gòu)升級，上來就分析業(yè)務場景，從來沒說要升級什么。然后直到最新方案。才隱約提出一個架構(gòu)定位。而從這個時候開始，架構(gòu)升級才艱難的進行了下去，但是圍繞分層，又出現(xiàn)了很多問題，比如分了7層，仍然在業(yè)務推演上有問題。
業(yè)務架構(gòu)
這里的業(yè)務架構(gòu)，主要是描述我們怎么設計業(yè)務功能的。因為只有劃分好了功能，我們才能達到代碼復用。才能隔離風險，提高研發(fā)效能，解決復雜業(yè)務場景落地等等等的問題。
業(yè)務架構(gòu)，就是描述系統(tǒng)的業(yè)務功能與職責。舉例來說，業(yè)務架構(gòu)就是描述我們具有哪些職責和功能，我們怎么和上下游分割劃分（L0）。比如交易系統(tǒng)劃分業(yè)務架構(gòu)：
對上：提供下單，支付，確認收貨，評論 等業(yè)務階段暴露
核心：交易單據(jù)，狀態(tài)流程，業(yè)務組件串聯(lián)
對下業(yè)務功能：創(chuàng)建交易，支付交易，庫存扣減，安全校驗等等
標準的方法中我采用的是三層架構(gòu)。注意這個可是和Controller，Service，Dao完全不同的概念。這三層是指：業(yè)務場景定義，平臺產(chǎn)品定義，平臺服務能力定義。
寫到這里，我發(fā)現(xiàn)一個問題，我主要圍繞一個非常復雜的背景：平臺架構(gòu)，在描述我的方法。也有可能有的同學沒有處理過這樣復雜的問題，或者沒有這部分的經(jīng)驗。首先，方法一定是相通的，能理解復雜的系統(tǒng)，沒道理做不好trade off，沒道理做不好簡單系統(tǒng)的業(yè)務劃分。此外，這是不是說明，我們做更多的事情，也更好的幫助我們自己成長。所以這并不是PUA的一種。
業(yè)務場景是描述整個業(yè)務身份，我們的系統(tǒng)要處理哪些”業(yè)務“。然后這些業(yè)務是按照什么維度進行劃分的。業(yè)務場景定義最難的地方在于”垂直拆分“的問題。即：為什么業(yè)務A和業(yè)務B是兩個業(yè)務。為什么不是一個業(yè)務。什么時候新增業(yè)務場景，如果一個業(yè)務A和業(yè)務B只有100行左右的代碼不同，怎么辦。等等這些問題。
平臺產(chǎn)品是描述”非業(yè)務相關，業(yè)務通用“的。某個特定的平臺型功能聚合。提供標準的擴展和標準的解決方案。比如”擔保交易“這是一個非常典型的平臺產(chǎn)品，淘寶，天貓都是基于這個交易鏈路來做的。
平臺產(chǎn)品最難解決的是”橫向拆分“問題。比如某個功能是不是平臺產(chǎn)品功能，還是只屬于某幾個業(yè)務的功能。
平臺服務能力是描述完全隔離的，獨立提供功能的代碼。注意一定是隔離的，并且獨立的。這是平臺服務的基本特性。比如一個資金轉(zhuǎn)移服務，安全校驗服務等等。平臺服務能力最難解決的也是垂直問題。就是什么是獨立服務，什么是服務配套。
這里可以展開說很多內(nèi)容，比如按照接口集成維度劃分場景，然后我們圍繞領域模型定義產(chǎn)品流程，這樣可以跨接口場景復用。然后我們的流程是基于領域模型DDD的。
下游核心服務，就是我們的DB（這也是洋蔥圈架構(gòu)標準定義）。所以我們把DB的操作定義成原子服務。這是一個非常簡單場景。但是如果我們是這樣思考和設計的。那么我相信這就是一個架構(gòu)師的能力標準。
業(yè)務架構(gòu)還包括一些核心內(nèi)容，比如：核心領域模型，核心業(yè)務流程等內(nèi)容。這些都是在具體實踐中。我們進行一些關鍵設計。
應用架構(gòu)
應用架構(gòu)，就是解決我們業(yè)務架構(gòu)然后代碼落地的問題。就是如何用代碼實現(xiàn)我們的業(yè)務架構(gòu)中的業(yè)務功能，如何組織我們的代碼，如何按照模塊進行劃分。
比如我理解的典型洋蔥圈架構(gòu)，就是一種應用架構(gòu)方法論。因為這里涉及到了DB。DB是具體技術的概念。在業(yè)務架構(gòu)中是不會出現(xiàn)具體技術的。比如”支付“是業(yè)務功能。這個功能甚至都不會是java來實現(xiàn)的。下游可能是一個系統(tǒng)。這里就是區(qū)分。
應用架構(gòu)是包含關鍵技術架構(gòu)的。因為應用架構(gòu)關注與“實現(xiàn)”層面的事情。
我的架構(gòu)經(jīng)驗比較復雜，這里不詳細展開了。主要是兩個框架：DSL框架和擴展引擎框架。我這里就介紹一種方案：基于不同業(yè)務場景擴展參數(shù)組合+workflow復用的架構(gòu)。
這是一種非常簡單的代碼組織方式，大部分系統(tǒng)都是用這種架構(gòu)方式的。核心就是基于功能action。然后業(yè)務中用到五個功能，就把五個action串聯(lián)起來就行了。
架構(gòu)延續(xù)
在業(yè)務發(fā)展判斷（前瞻性）里面，我描述了我們的業(yè)務能力，業(yè)務sense怎么提升。但是，我想說明的是，作為架構(gòu)師，我們的業(yè)務能力，最終還是為架構(gòu)服務的。當然了，繼續(xù)往下個階段，就不一定了，因為解決問題的手段不僅僅是“架構(gòu)”這一個手段了。
基于我們對業(yè)務發(fā)展的判斷，我們框架部分的靈活擴展設計。是否就能保證我們的架構(gòu)核心延續(xù)下去呢？其實我覺得還不夠。
因為架構(gòu)延續(xù)，不僅僅是能完成業(yè)務功能。同時還需要保證我們的核心領域模型，架構(gòu)分層，核心架構(gòu)概念，技術風險，研發(fā)效能。這些部分能夠持續(xù)不斷的演進，不說變好，至少沒有那么快的變壞。相信這個問題都有感覺，因為一個5年左右的系統(tǒng)，代碼經(jīng)常被稱之為“屎山”。我們經(jīng)常戲稱我們的工作就是屎上雕花。那么怎么能夠做到架構(gòu)延續(xù)呢？
我從一個比較感性的角度來說明這個問題：架構(gòu)隱喻
這是我在XP極限編程里面學習到的一個概念，里面很多內(nèi)容我并不能贊同。但是這個核心方法我還是保留了下來，然后結(jié)合我的工作進一步的解釋和落地。
另外，我是一個絕對的“英雄主義史觀“。在我看來，所有的制度，流程，業(yè)務設計，架構(gòu)設計。最終都取決于人這個因素。我們沒辦法很好的限制人，我們只能按照”感性“的維度，去引導大家。架構(gòu)隱喻，就是一種具象化的，感性化的。讓相關同學都能理解和明白相關架構(gòu)定位和發(fā)展方向的”感覺“。依托這種感覺，我會不斷的進行我們的架構(gòu)迭代。朝著我們的目標方向發(fā)展。好的架構(gòu)一定是延續(xù)的。
下面我還會講一些具體的方法和拆分的維度，但是這個是屬于頂層概念。一定是基于”架構(gòu)隱喻“才能讓大家保證執(zhí)行不出差的。否則無論是什么方法，只要提出了，都還需要解答另外一個問題：如何保證別人落地的過程中和你想的不出現(xiàn)gap？
在具體的架構(gòu)延續(xù)方法上，還會分幾個部分（上面也說了）。
核心領域模型
我們的架構(gòu)設計，一定是圍繞核心領域模型來的，基于我們的判斷設定的。如果核心領域模型需要發(fā)生變化。那么就是另外的一次架構(gòu)升級，這個時候往往是翻天覆地。所以盡量保證核心領域模型不變，即地基不變。
架構(gòu)分層
明白核心領域模型之后，思考我們的架構(gòu)分層，在分層上可以做到內(nèi)容的橫向擴展，而不是分層擴展。比如我們設計了平臺產(chǎn)品，盡量進行平臺產(chǎn)品的多樣性，可以自由組合設定，而不要再把平臺產(chǎn)品抽象成一些所謂的前臺產(chǎn)品，后臺產(chǎn)品。因為往往用”多加一層“的手段，去解決業(yè)務問題的時候。是得不償失的。我們往往可以通過多加一層的手段去解決技術問題。比如ACL，這種防腐層的設計，在業(yè)務語義上面沒有任何的變化，這種就是純技術適配，還有比如各種場景識別，不同的API（http，RPC，消息）的接入層。如果是加分層的手段是解決業(yè)務問題，往往不行，比如業(yè)務層這個概念。我們很容易拆分出 業(yè)務場景層，業(yè)務流程層。但是這又有什么意義呢。還是要增加很多很多的概念去解釋怎么劃分這兩層。（半文鏈接理論）所以 架構(gòu)敏捷度=處理問題個數(shù)/架構(gòu)概念個數(shù)。我們盡量保證的是概念更少，而不是更多。
擴展引擎技術
這個會和trade off來說明。我一直認為，架構(gòu)是一定一定不能解決所有問題的。所以不要反人性的去阻止大家寫特殊的if。而是能夠讓大家不寫if（更簡單），獨立寫if。這個就是擴展引擎部分。
架構(gòu)trade off
如果業(yè)務不發(fā)展，那么根本不用架構(gòu)。當下的代碼就可以用，為什么要設計架構(gòu)呢？所以架構(gòu)一定要解決未來的問題，那么架構(gòu)就不能全解決當下的問題。那么當下的問題全解決是否可以呢？也不行，因為有的業(yè)務不發(fā)展了，那就也不用解決。有的問題還在發(fā)展，首先要解決的是發(fā)展，有的ROI很低等等。
上面說明了。架構(gòu)一定是要trade off的。沒有銀彈，需要面向未來。就一定容忍我們當下的一些妥協(xié)。這也是我一直說的：做不做架構(gòu)升級需要很保守，架構(gòu)升級方案需要很積極。
在實踐過程中，上面兩個事情最終決策的人往往是同一個，所以架構(gòu)升級往往不如人意。（不能又保守，又激進）在接受了架構(gòu)需要trade off之后，其實我們面對的大部分是”多少“的問題。比如有100個問題。我們能容忍21個？還是22個。這也是我在架構(gòu)發(fā)展階段里面說的”“共識”問題。這就需要結(jié)合不同的業(yè)務場景和當前業(yè)務階段來定義了。
我能給出的方法是：基于架構(gòu)定位，設定架構(gòu)目標。設定核心問題，核心問題必須解決。其他的其實都不影響主體架構(gòu)。這也是一個完整的架構(gòu)方案里面，需要體現(xiàn)架構(gòu)目標的原因。
流程與機制
需求迭代流程，代碼研發(fā)流程，系分流程，穩(wěn)定性保證機制等等。
通用技術方案（包含設計）
這里就是通用的技術方案，這個和業(yè)務無關，但是又有別于標準的框架知識。是一些常見下的標準技術解決方案，比如分布式事務，多活等。這些特定問題的解決方案。我這里羅列一下，大家可以去了解一下
技術方案部分
這里是純技術，需要每個都非常了解：
tcc
jta/xa
saga
最終一致性
冪等
典型技術方案
ldc
分庫分表
高并發(fā)拆分
集群
多活&熱備
分布式鎖
唯一性管控
設計方案部分
這里講的是類似設計模式，用一些通用設計方案，解決我們遇到的問題
acl
執(zhí)行模板
流程式
多策略
流程化
AOP
設計模式
為什么在能力里面沒有介紹純技術,技術框架呢?因為高級開發(fā)就應該達到了。
