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