架構方法論：如何自底向上推導應用邏輯？
????
點擊閱讀上篇：??從方法到思維：什么是應用邏輯架構的正確姿勢???
五 架構的基本約束
架構約束分成了基本約束和業務約束：
- 邏輯架構基本約束：是軟件工程領域常見的各種軟件設計原則。
- 邏輯架構的職責約束：是模塊，子模塊，模型的職責相關約束，尤其是核心的模型和核心主模塊是在一定時間內是比較穩定的，所以此時對其定義它的約束范圍是有助于這段時間內的研發的效率的。
- 各種架構的非業務功能性約束，如穩定性，性能，成本等等。
而本文講到的約束基本是邏輯架構上約束，如果考慮業務約束，我們還必須要考慮我們的面向的客戶是什么群體之類的約束，如果缺少這樣的約束，在設計產品時可能會走偏。
5.1 常見的軟件設計原則
- 單一職責原則(SCP)(參考 grasp 原則)
- 開閉原則(OCP)
- 子類替換原則
- 依賴倒置原則(DIP)
- 接口隔離原則(ISP)
- 組合聚合復用原則(CARP)
- 迪米特法則(LoD)
以上這些原則都是判斷標準，那么是用什么方法論來實現軟件可以幫助我們的軟件符合這些原則的呢?答：設計模式。
5.2 常見設計模式
這里有兩個非常重要的關鍵詞：判斷標準 + 實現方法，這里判斷標準是軟件設計原則，實現方法設計模式。
作為一個常年在軟件行業摸爬滾打的人，設計模式和設計原則應該是較為熟悉的，或者說常用的設計模式和設計原則都是比較熟悉的。但是大部分書籍講到的是模塊內部如何使用設計模式，并沒有重點強調邏輯架構中模塊之間如何使用設計模式來讓邏輯架構遵循軟件設計原則。
而我們設計或者推導邏輯架構時，主要就是用設計模式等方法來讓邏輯架構中的各模塊之間的關系，以及模塊內部的子模塊之間的關系符合軟件設計原則。
5.3 關于模塊
如何用設計模式來讓模塊間的集成符合軟件設計原則，從而降低維護和擴展的成本。架構中的模塊之間，模塊和子模塊，子模塊和子模塊要遵守軟件設計的相關約束。如何遵守呢，領域建模和設計模式是兩個具體的方法。
即使不考慮模塊之間邊界和約束，光考慮模塊內部的設計，軟件設計原則和設計模式就已然是我們軟件工程師的必修課。再加上模塊之間的依賴或者邊界更加需要軟件設計原則和設計模式，那它們的地位就更加神圣不可替代。值得不斷的深入學習，實踐，思考和總結，這也是為設計邏輯架構打基礎，架構師必修課。
雖然我們一開始總是從濫用開始，不過沒關系，一開始要做到不偏不倚總是很難的，慢慢的我們就可以窺見的其中的奧妙。
5.4 具體技術在某些特定場景下的約束
這是具體的技術在某個特定場景下的約束：
- Web 研發常見的規約，比如說重復提交，事務，多版本。
- MySQL 的在高并發場景下的使用規約，比如說各種分庫分表的規則，索引規則等等。
- 高并發相關系統中的相關約束，比如說冪等控制，并發控制，緩存策略，線程使用，鎖粒度，各種循環內調用遠程接口或數據庫等等。
- 其他。
總的來說，這里的這些約束更偏向于物理架構上的約束，這里還是提前描述一下。同時每個物理架構要解決的問題不一樣，導致它們要遵守的計算機科學與技術上的約束是不一樣的，這是架構師們要整理，并倡導執行的。
5.5 邏輯架構中的業務屬性約束
前面講到的是軟件研發領域的基本約束，這些基本約束在高粒度模塊中一般很少被提及，高粒度模塊之間的約束關系是根據業務中的思維概念提煉而來，比如電商中提煉出訂單，營銷活動，商品等等核心概念和核心域，對這些核心概念進行定義，以確定它們之間的關系和邊界，從而形成技術上的統一業務約束。
同理，任何一個領域應該都存在這樣的約束，只是這樣的約束并不是一層不變的，尤其是在業務系統中，業務理解發生了變化，這樣的約束也會隨之變化，而且業務中約束的目的是驅動業務更好的前進的重要保障。
我們拿國家這個架構來做簡單的解讀，讀了十年歷史，大概總結出的一個國家級別主要架構約束是這樣的：
歷史上不同時期的國家治理有不同的架構(三省是頂層模塊，六部是二級模塊，然后依次做模塊分解，直到一村，一戶，這戶可以看最是領域模型)和規約。西周和東周的春秋時期靠的是周公旦制作的禮和樂作為國家架構的約束，到了戰國時期，禮崩樂壞，百家爭鳴，最終以統一國家為目標的法(這個法和保障民生的法是兩回事)成為秦國的架構約束，得以讓他成功統一六國，但是很快這種法的約束又帶來了副作用，于是漢朝建立，確定孔子的儒家倫理道德作為國家架構的主要約束。
然而這種以倫理和道德為主的架構約束對王朝的前 100 年 - 150 年是非常有效的，但是隨著時間的發展，這樣的約束會越來越弱，約束變弱則利益集團會不斷的讓架構中的模塊邊界變的模糊，有些模塊的利益變的更大，有些模塊的利益更小了，而且依賴關系變的混亂，從而使整體架構的利益受到影響，同時由于利益牽絆太深很少有一個總架構師有能力扭轉乾坤。最終于就會被另外一個王朝所洗牌，新的王朝會重新建立架構，重新設定模塊間的邊界和依賴，同時還是以道德和倫理作為主要的約束。這種局面從漢朝開始周而復始了 2000 年。
不管怎么說，一個符合時宜的架構約束是有利于架構向前發展的，而不符合時宜的約束反而是制約者架構發展的。各種內耗等情況應運而生，最終阻礙了業務向前拓展。
5.6 約束小結
縱上所述，模塊間約束無處不在，技術上的約束是最最容易看懂的。越是細粒度模塊的約束，我們越容易學習和理解，比如軟件設計的原則等等，越是高粒度的模塊的約束，越抽象。需要對業務有深刻理解，對組織有深刻的理解，甚至對社會有深刻的理解。
六 邏輯架構復用
6.1 復用
件復用包含很多內容，比如說設計的復用，文檔的復用，代碼的復用等等。在本章節中的復用特指代碼的復用。
復用的收益
提煉的目的是實現復用，復用的目標收益是：
- 軟件的研發效率的提升
- 研發成本下降
- 軟件質量的提升
- 等等
復用的分類
對于復用，我從業務功能和非業務功能的角度來分了一下類，如下：
1)一種是跟業務無關的一些可復用的內容，這些內容存在于基礎架構的每一個層次，但是還不能歸屬于邏輯架構，而且業務技術無關的復用不是本文討論的重點，所以本文不會重點闡述 MVC 的設計思想是如何在不同的 Web 應用中得以復用的。
- 框架的復用，spring, mybatis 之類的，對于框架的研究，業界從來沒有停止過腳步
- 數據結構，算法，網絡，等封裝庫，比如 Apache 和 Google 的各種封裝庫
- 中間件(RPC，Queue，cache 等)及各種存儲，監控報警等基礎設施
- ORM，IOC，AOP，MVC，BPM，Rule Engine 等等對應的框架，這些都是和業務無關的復用
- 等等
2)還有一種是跟業務相關的可復用內容，它的產生取決于抽象能力和技術功底，比如：
- 系統模型復用：營銷活動中存在各種規則，那么這些規則應該如何抽象以達到可以被復用的程度呢?比如我們將規則中的節點可以抽象成單獨的算子，比如說滿足某個條件，執行某個優惠動作，那么滿足和某個優惠動作都可以抽象成算子(在 UMP 中被稱為元數據，我們也沿襲了這一叫法)這些算子可以被復用且隨意組合，以形成新的活動規則。
- 流程的復用，比如每種電商平臺，都需要有交易流程，包括信息流，資金流，那么天貓，淘寶，聚劃算等的交易流程是否可以復用，如果可以應該如何復用，是否可以將相同的和不同的環節區別對待，以實現可復用性。
- 計算模型 & 框架的復用，比如說營銷中的疊加互斥計算模型，session 包的復用，特定業務中的測試框架的復用。
業務模塊復用的形式(物理架構中要考慮的內容)
具體的復用形式本質上來說是物理架構中要考慮的內容，這里捎帶提一下。
1)二方庫形式
提煉成二方庫，誰使用誰依賴這個二方庫，這種情況又分成了兩個子類：
- 純邏輯，沒有數據的存儲等，其計算完全依靠調用者傳入的數據，比如說某個業務場景的規則引擎，某個業務工具包等。
- 有負責數據的存儲，比如說在二方庫中直連另外一個服務(也可以看做胖客戶端)，或者直接連接數據庫，這種方式在網站早期比較常見。
2)服務化形式
下沉成服務，通過接口對外暴露，技術手段多種多樣，比如說 HSF，SOFA 對外暴露，或者 HTTP 對外暴露等，但是這里的重點不是在使用什么樣的技術手段，而是暴露的服務中應該包含哪些內容(有多少客戶，他們的需求的共性是什么，我們的業務本質是什么，根據這些內容來設計我們需要暴露的服務，然后在考慮我們接口的規范。至于使用什么樣的服務容器之類的內容基礎設施架構同學會重點來考量，我們需要需要學習和理解，但是我們的重點還是在前兩個，即服務到底是什么，以及服務接口的規范是什么，在這兩個上苦下功夫，對業務線的同學拿結果以及個人成長都有莫大的幫助)
3)展示組件
還有我們前端的各種可復用的展示組件的設計，比如說 TMF 的可復用組件等等。
邏輯架構中的可復用模塊的落地表現形式優劣
跟業務無關的可以復用內容我們在本文中暫不討論，本文中我們討論一下跟業務相關的跨模塊復用的兩種情況，以及這兩種情況之間的異同：
在跟業務相關的跨模塊可復用情況中，慢慢的大家都以后者(下沉成服務)作為主要的表現形式，原因有便于發布，變更影響小，等等。雖然后者在調用時有一些遠程開銷，但是得益于 RPC 簡潔的二進制協議(CPU Time 的下降)和日益變小的 RTT(RT 的下降)及日益增加的帶寬，其遠程開銷的代價漸漸變得不那么顯眼，甚至可以忽視。
那么是不是后者是不是可以代替前者呢?也并不是這樣，有的場景下前者是不能用后者來代替的，比如說通過業務流程的提煉抽象而得來的業務二方庫，這個是無法通過服務化來代替的，反而這種情況下，往往是服務化+二方庫同時出現，起到一個很好的復用的作用。
所以在業務線的應用邏輯架構中，復用的重點即在提煉出共同的特性(模型上，流程上，計算模型上等)，然后以二方庫或者服務化應用的方式來進行落地。那么如何在邏輯架構中提煉出共同特性呢?
6.2 抽象和提煉
抽象和提煉基本上會從下面幾個點出發：
- 有類似的模型或者屬性
- 有類似的流程
- 有類似的數據結構和算法
我相信很多人都有過這樣的經驗。由此可見提煉就是陰陽調和：
- 抽象與架構：對業務的理解，根據領域建模的方法和設計模式產生領域模型抽象和流程抽象，或者計算模型的抽象等等，然后根據這些抽象設計出合理的架構，并讓架構健康的向前迭代。
- 計算機科學與技術：對技術深度的把控，包括編程語言，各種框架，SDK，多線程，數據結構，各種網絡編程包，各種 xx 引擎(如規則引擎，流程引擎等等)。
而這些都需要工程師們對領域建模和設計模式的抽象技術，以及對相對的技術特性等計算機技術的深入掌握。這里需要強調光知道領域建模和設計模式等是不夠的，不同的技術選型特性不一樣，會導致在抽象的實現時產生不同的差別。
在復用這件事情上，抽象技術和計算機技術兩手抓，兩手都要硬。如果用中國古代傳統思想來比喻，那可能可以用陰來比喻抽象技術，陽來比喻計算機技術。 尤其是陰，總是給人捉摸不定的感覺，但是如何深入學習，堅持實踐總結，我們就會發現陰原來也是有具體方法論的，但是這個具體方法又不是看看書就能學會的，它對知行合一的要求更高。
從學習的步驟來說，一般的過程都是先從陽(計算機科學與技術)開始，因為先從陰(抽象和架構技術)開始沒有陽作為支撐是很難把陰融會貫通的。而且最終要達到的是陰陽調和。如果我們過于偏重陰或者過于偏重陽，都會導致陰陽失調，大概就是這個意思。
來到數據部門之后，我發現已經不能用陰陽來形容我們要學的領域了，現在我們搞的比較多的是統計分析和機器學習(統計分析和機器學習有交集，也有區別)，所以目前對我們團隊來說，我們的同學有三門學科是必須要掌握的：
- 計算機科學與技術
- 抽象與架構
- 統計分析與機器學習
我最近一年看的比較多的是統計分析，有同學釘釘我問道：怎么連你也放棄領域建模了。我沒放棄，領域建模是抽象和架構的重要方法(但不是唯一的方法，演繹和歸納也是，自頂向下分解也是)，工程技術同學是不能放棄的。學習統計分析及統計學習是因為統計學習 + 計算機科學與技術可以更好的解決工程領域遇到的問題，這也是各條線的工程師需要掌握的技能。
6.3 復用小結
復用是軟件中一個非常重要的學問，里面結合了抽象技術和計算機技術，而抽象技術還依賴于對業務的理解程度，所以此非一日之功，需要長時間的鍛煉才能有所小成。
當然，有時候即使在技術上可以抽象提煉，但是由于組織架構的問題也會讓這樣的提煉無法落地，或者這里并不是一個穩定的結構從而導致經常調整，帶來的結果是提煉的投入產出比比較小，從而導致無法提煉，這些這里就不詳細寫了。
七 邏輯架構分層
7.1 分層的分類
工程骨架分層
分層幾乎是從每個工程師入門的時候都會接觸到的一個普世的概念，在一些書籍里，分層有的被稱之為 tier，有的被稱之為 layer，比如說 OSI 分層模型是用的 Layer 這個詞。而在一些文章里講到架構時用的是 tier 這個詞，當你去查看 wiki 的時候，那就更暈了，因為 wiki 離 tier 和 layer 是混在一起講的。
談到分層，各種教科書中分層無不拿出景點的 3 個層次來闡述分層問題，如下：
- presentation layer
- business layer
- data layer
然后還有擴展出 service layer，這些在工程骨架中非常常見，我們幾乎從來沒有見過不分層的工程骨架，所以當我們討論架構分層的時候，很多人腦海里第一映像就是工程骨架中的分層。
工程骨架的分層的一個重要目的是：成為代碼組織結構的約束，防止代碼混亂不堪。
邏輯架構分層
但是我們講的邏輯架構分層不是指工程骨架分層，為什么不是?首先來看一下邏輯架構的特點：
- 源于業務概念架構(源于業務分析)，保留了業務概念架構中大多數的業務功能模塊，但是又會通過對技術的提煉從而比業務概念架構更加復雜。
- 邏輯架構中上下左右模塊之間存在依賴關系，所以確定模塊依賴關系是一個非常重要的話題。
- 邏輯架構是分片的，一般來說同一個層次會存在多個模塊，像兄弟一樣。
根據這個特點，我們可以模糊的看出邏輯架構的分層主要是邏輯架構中各模塊的調用關系，甚至更偏向從模塊職責的角度來進行歸納從而得出層次。
這種分層的目的是：對同一類職責的模塊進行職責上的約束，此時還不一定有代碼的存在。
兩者的區別
這么看來這兩個分層是有著本質的區別：
- 目的上：邏輯架構中的分層是邏輯架構中各模塊間的依賴層次關系，以及模塊的再抽象。而項目骨架中的分層是代碼的組織形式的一種約束。
- 形式上：某個邏輯架構中某個層次上的應用內部依然是存在工程骨架分層的，比如說購物車模塊依賴了營銷模塊和商品模塊，他們在邏輯架構上可能是不同的層次，但是購物車，營銷內部的工程骨架上依然進行presentation， business, repository 之類的分層。
也許有的同學會說了，再大的架構(就比如說某個 BU 的邏輯架構)，我也可以將最靠近用戶的模塊劃分成 presentation layer，中間的所有模塊都劃分為 business layer，最下面的我都劃分成 presentation layer。沒錯，你可以這樣做，但是這樣做基本沒有任何意義，不能帶來指導作用，失去的分層的目的。
7.2 分層的案例
在文件系統或者網絡協議上，也有各種層次的封裝。如下圖所示：
?? 
這個圖中每個模塊在不同階段都有不同階段要解決的問題，然后每個模塊都可以分解，產生更細粒度的模塊，這里重點是讓大家了解到什么是邏輯架構中模塊的分層。
- 宏觀上來看，處于上層的模塊會依賴處于下層的模塊
- 同一層的模塊有時候也會產生依賴關系
- 在層次上可以用箭頭標注數據流或者調用流
不過這些都不是問題，問題是什么呢?
問題是我們必須時刻知道，目前我們在不同層次的這些模塊存在哪些問題，以及不同層次在解決什么問題。比如說上述的操作系統中文件系統和協議分層中，最底層的是跟硬件打交道，能夠精準的控制硬件，中間是對操作系統的用戶暴露的，更簡單易用，上層是針對應用來使用，解決特定領域的問題，不同的層次做了不同的抽象，也是在解決不同的問題。
7.3 某些領域建模書籍之中的分層
很多人及一些書中，談分層必談工程骨架的分層，這個分層和架構中的分層是兩回事，如果我們在談架構，那么我們要避免把重心放到項目骨架的分層上。
比如說領域建模的相關書籍中，經常會講到 service, domain, repository 之流，這個些概念處于架構中的什么位置，我們應該什么時候去關心這些概念?
?? 
如圖所示，在細粒度模塊內部，按照純技術職責來進行劃分時，我們將之擼成 service, model, repository,integration 之流的工程骨架，值得注意的是工程骨架的劃分層次和具體的業務邏輯架構是沒有關系的，他更偏技術，他的職責是對代碼做一個高層次的組織和管理。
按照正常流程，系統模型產出之后，應該緊接著考慮模塊的設定，依賴，規約，但是很不幸，很多書籍和資料都把 service, model, repository,integration 這部分分層的內容作為了領域的建模的最重要的重點之一。
某些書里的這種觀點是不符合實際工作流程的，實際工作時，在領域模型之后我們先考慮的是架構中的各個模塊的位置和職責，以及模塊內部的子模塊，模塊之間的關系，以及整體的約束等等(請參考文章開頭對架構的定義)。具體表現就是我們在邏輯架構圖中不會去畫什么 service, model, repository, integration 之類的層。
工程骨架的分層在細粒度模塊內部，這是基礎設施架構的一部分，也許是你手頭目前最重要的部分，但是對于整個應用邏輯架構來說不是最核心的部分也不是最需要先考慮的內容。也就是說，即使你不分 service, model 之類的，對應用邏輯架構中模塊的職責劃分也是沒有影響的。
同時我也見過一些項目，應用邏輯架構比較明確了，但是在落地到物理架構時，把邏輯架構中的所有模塊都放在 service 包里，而且沒有再分包，這就不合適了，邏輯架構中的模塊完全沒有落地。
所以我現在在我們部門的項目中，堅決避免將 service, model, repository,integration 之類的放到最高層來考慮。而是將邏輯架構的設計切切實實的落地，這樣根據邏輯架構，我們就能看到的我們具體的應用，和應用內包的組織情況。
再次強調：邏輯架構中的分層不是指 service, model,repository, integration 之流的分層，而是指功能模塊的分層。如果不了解業務，如果不了解業務概念模塊，如果沒有業務概念架構，我們是很難做出合理的應用邏輯架構的(當然也包括邏輯架構中模塊的分層)，撇開業務特征直接談邏輯架構的分層是不行的。
模塊的職責確定之后，模塊之間的依賴也必須要確定，然后模塊對外暴露接口需要定義規范和技術實現的手段。比如，如果是 restful 接口，那么應該是什么樣的規范對外定義，如果是內部的服務的接口，應該是什么樣的規范。由于本文篇幅所限，此處不進行詳述，前者可參考各大平臺的開放接口，后者可參考各 BU 內部服務調用的相關規范，如果沒有，那說需要制定一個統一的規范。
八 邏輯架構是分粒度的
8.1 邏輯架構顆粒度樹
這里我引入了一個新概念：邏輯架構顆粒度樹。
剛剛講的都是 2 維上的架構，我們可以看到，架構推導是有方法的，而且如果對方法進行提煉，就是橫和豎的問題，但是正如我們開始講到的，架構也可以是 3 維的，那就是在二維的模塊中存在各種粒度子模塊或者父模塊。
如果非要打個比喻的話，那么下面的宇宙星神合體是一個大的架構：
?? 
里面分成了很多小模塊，比如物質飛船，探測器等等，而每個小模塊又是有很多基礎模塊構成，宇宙星神合體中只有 3 個層次，及基礎部件，模塊，及最終的星神合體，它們代表著不同的粒度。而對于業務復雜的架構來說，粒度會更多，層次就會更多。這取決于N個研發資源投入在某個模塊上的效率最高，而這個 N 在某個階段的技術限制下應該是一個比較穩定的值!
抽象一下，模塊在不同粒度上，可以整成這么一棵樹：
?? 
邏輯架構粒度樹的 3 條原則：
- 縱向上，任何一層次的模塊的職責，都必須是下一層職責的概括
- 橫向上，同一層次的模塊職責屬于同一范疇
- 橫向上，同一層次的模塊的邊界清晰
上述的樹形結構，只能描繪出模塊和父模塊，子模塊的關系，但是不能完整的描繪出模塊之間的關系，是處于同一層次，還是處在不同層次(就是前面提到的應用邏輯架構中橫的問題和豎的問題)。
那么用什么樣的圖形既可以生動的表達出模塊和父模塊，及子模塊的關系，又能表達出不同模塊之間的關系呢，我想了很久，也沒有想到一個更容易理解的圖形，最后產出了下面這么一幅圖：
?? 
圖中有三層，但是現實生活中可能超過三層，也可能低于三層。我們能歸納的層次越高，那可能我們接觸的東西就越寬廣，越精深。
這里有一個嚴肅的話題需要提一下：是不是一線工程師不用考慮邏輯架構問題?當然不是，任何一個同學，你手頭的工作都是跟架構相關的，你負責模塊可能也存在子模塊，而且必定會存在父模塊，出于工作，你必須要理解不斷迭代你模塊中的設計，同時隨著能力的成長，你必須要關注你的父模塊，父模塊的父模塊，日積月累，你可以 hold 住的模塊粒度會越來越大，你的職責和能力要求會越來越大。
8.2 模塊顆粒度樹落地情況
在下述架構模塊顆粒度樹中，并沒有模塊和模塊之間的依賴關系，這里只是為了概要的說明模塊落地到物理架構中的一個演變過程，而具體的案例我們放在后面的文章中來進行闡述。
模塊樹上的這些不同粒度的模塊，在具體落地成物理架構時，可以是不同的形式，如下：
- 可能是子包
- 可能是頂層的包
- 可能是應用
- 可能是一組應用的集合，負責某種職責
- 也可能是某個平臺(如營銷平臺，商品中心等)
- 更有可能更大層次的平臺，比如 B2C
為什么會出現這種情況呢，因為不同的模塊在業務的發展的不同時期：
- 模塊中的邏輯的復雜度不一樣
- 模塊的粒度本身也在發生變化
那么我們來看看一個網站從小到大的邏輯架構模塊樹落地的變化情況。
小型業務邏輯架構的模塊樹落地情況
?? 
很顯然，這里是一個電商網站起步時候的樣子，所有模塊都有模有樣，只是模塊中的邏輯比較簡單，這些模塊都以包的形式存在于一個應用之中，這個應用是一個大泥球。但是由于模塊的職責劃分合理，粒度的治理也比較符合發展要求，所以這樣的應用在分拆成分布式的時候阻力會比較小。而那些模塊職責不合理的大泥球應用，隨著業務的發展，要分拆成分布式應用，阻力就大很多。
中型業務邏輯架構的模塊樹落地情況
?? 
這是一個度過初期階段的電商網站，營銷，商品，交易模塊等已經成型，而且得益之前的模塊劃分，架構師可以很快的將初期的多個頂級包，分拆出來，變成多個應用。
大型業務邏輯架構的模塊樹落地情況
?? 
到了這個時期，已經是一個大型電商網站的樣子了，營銷平臺內部已經分拆出了多個應用，得益于上一階段中各模塊職責的合理分配，所以架構師將在將物理架構進化成這個樣子的時候，力氣不需要花在邏輯架構的治理上，可以把精力集中投入到物理架構及基礎設施架構的建設上，比如同城容災，異地多活等等。
8.3 再發展成巨型的架構呢?
中臺概念抽象
我不知道，比如中臺是不是，要把電商業務中所有的相對穩定的核心抽象出來，可能是領域模型，可能是業務流程轉換而成的系統流程，可能是一個計算模型或者算法等等。然后變化的內容(前臺)可以依托于這個大的核心概念快速的迭代。如果需要圖形化來做概要的理解，我想應該是這樣的：
?? 
一旦要做一個中臺，那么以為著這個中臺對前臺來說就是一個技術產品，則要考慮如下幾個方面的內容：
- 穩定性性能的要求是極高的，需要有體系化穩定性和性能體系
- 產品運營是非常重要的，到售前，到售后有一個完整的流程
目的就是要提高客戶的生產效率。
是否存在中臺的判斷依據是什么?
多個業務線有無重復的流程抽象，有無重復的領域模型抽象，有無重復的計算模型(數據結構和算法)等等，有無重復的輔助性設施。他們是否在重復建設，等等。
在演變的過程中變化是什么呢?需要的是學習能力，溝通能力，協調資源的能力，領導力，影響力，評估人的能力和用人的能力等等。這些能力需要涉及的范圍都從一個小的組織向一個更大的組織前進。
大音希聲，大象無形，不管如何發展，基礎的規律都還是不變的。
8.4 邏輯模塊落地的相關考量維度
當一個邏輯模塊要落地時，我們如何判斷一個模塊落地成包，還是應用等等，有很多判斷的維度，比如：
效率(多少人維護一個應用效率最高)
到底多少人的團隊協作效率最高?作為一個應用，在技術不斷進步的情況下(比如說新的容器之類的)，或者要面對的業務的復雜度不同的情況下，同時可維護的人數也是不一樣的，具體目前變化到多少，目前基本是靠經驗，然后遇到問題再調整，根據主管的經驗不斷調整和優化，以達到一個適合當前階段的最優值，目前我自己這邊大概5人左右一個攻堅小組，遇到更大問題域，那就拆解。
穩定性
- 強弱依賴
- 核心與非核心分離
性能
- QPS，包括模塊內部的技術實現，是使用多線程還是協程，容量評估，到壓測，等等，里面大量的內容。光是線程這一節就有需要研究很久最大 QPS 推導及同步異步問題：
- RT，減少 wait time? 減少 cpu time?從瀏覽器，到網絡，到服務器，到存儲等每個環節，比如說網絡上有一個重要的公式：BDP = BD * RTT，把這個公式背后的相關知識點搞清楚，那么網絡優化的很多方法的理論依據我們就搞清楚了。
這里面，效率，穩定性，性能是最影響邏輯架構落地成物理架構的三大主要因素。
九 全文總結
9.1 架構的定義和價值
我們在文章的開頭對架構兩個字給出了一個官方定義，然后按照筆者自己對架構的理解又對架構進行了分類，在架構分類中，出現了產品功能架構，業務架構，應用邏輯架構，應用物理架構等等。
不同的架構都是在解釋不同的問題，比如：
- 產品功能架構強調的是功能模塊能力，受眾是最終使用產品的用戶等。
- 業務架構是對業務的一種分析和理解，用來如何更好的構建產品，受眾是產品的同學和技術同學。
- 應用邏輯架構強調的是研發時，各邏輯模塊的職責，受眾是研發的同學及架構師。
正確分析出當前的場合(受眾和目的)應該用什么樣的架構來闡述我們的意圖是非常重要的。
同時我們可以看到小到一個mis系統，大到整個阿里，都可以用架構的角度來解釋，架構中出現的各種中臺，后臺，各種框架等等其實都是架構方法產出的結果。系統大小不一樣，抽象的方法是類似的。
架構產生之后，隨著業務的迭代，架構不治理，模塊職責和依賴，層次不清晰，約束不明確。穩定性，性能，成本都受到影響。積弊越久，回頭越難，有時候不得不重頭來過。
9.2 自底向上重度依賴于演繹和歸納
為了避免推倒重造的問題發生，我們需要不斷的自底向上的方式來修正架構，修正其實是在做局部的模塊重構，談到修正，具體的方法是由這里就不得正視歸納和演繹的重要性了，而這里的演繹和歸納是抽象的核心概括。
自底向上的推導的重點在于演繹和歸納，越是底層的越是要使用演繹的方法，越是高層的越是使用歸納。
這兩種方法應該什么時候使用?顯然當我們的目標(比如說業務目標)或者結論是非常高粒度的時候，需要分解，那么使用自頂向下的推導，在規劃未來時一般會用到類似的自頂向下的方法，產出我們宏觀結論。
而如果是產品方案已經明確，程序員需要理解這個業務需求，并根據產品方案推導出架構，此時一般使用自底向上的方法，而領域建模就是這種自底向上的分析方法。
對于自底向上的分析方法，如果提煉一下關鍵詞，會得到如下兩個關鍵詞：
演繹
演繹就是邏輯推導，越是底層的，越需要演繹：
- 從用例到業務模型就屬于演繹
- 從業務模型到系統模型也屬于演繹
- 根據目前的問題，推導出要實施某種穩定性措施，這是也是演繹
歸納
這里的歸納是根據事物的某個維度來進行歸類，越是高層的，越需要歸納：
- 問題空間模塊劃分屬于歸納
- 邏輯架構中有部分也屬于歸納
- 根據一堆穩定性問題，歸納出，事前，事中，事后都需要做對應的操作，是就是根據時間維度來進行歸納。
關于歸納，我們前面已經做了大量的講解，所以這里我們重點闡述一下演繹：
1)我們從對業務的理解，演繹出用例，從用例演繹抽象出業務概念模型，從業務概念演繹抽象出系統模型，從系統模型演繹抽象出物理存儲模型。這是一個從 A 推導出 B，從 B 推導出 C，從 C 推導出 D，從 D 推導出E的過程，而在 B，C，D 上又有很多邏輯分支。推導出的層次越深，邏輯分支越廣(保障每層的準確度的基礎上)，一般來說實力越強。
2)我們從對業務的理解，演繹出用例，從用例演繹出業務流程，再從業務流程演繹抽象成系統流程，然后再演繹成數據流。這是也是一個從 A 推導出 B，從 B 推導出 C'，從 C' 推導成 D'，從 D' 推導出 E' 的過程。這個推導過程比如有方法論輔助，否則邏輯的深度和廣度都會受到影響。
總的來說：演繹推導的層次越深，分支邏輯越多，越能穿透迷霧，看問題就越透徹，說明功力越深厚。
打個比喻就是：對應相同品種的樹來說，小樹的根系和大樹的根系在地下深入的長度和廣度是完全不一樣的，人的邏輯能力大抵也是如此。
其實我們工作中很多時候都在使用演繹和歸納，只是我們不知道我們在使用這類方法，看到這篇文章之后也許可以給大家帶去一些思考，看清楚我們自己以前的工作到底是如何使用演繹和歸納的，以及如何改進以前的方法。
9.3 邏輯架構的自底向上推演
除了自底向上的通用思考方法之外，我們還必須要了解計算機領域的相關技能和套路才能產出合適的結果：
?? 
這張圖是有嚴密的邏輯路徑的，每個步驟的輸入，都是上個步驟的輸出。更關鍵的是這個張圖是有順序的，做架構要從上往下做，不可自顧自，不可撇開業務閉門造車。
為什么前面我們問題空間領域模型聊了這么多，原因就是問題空間的領域建模其實是分析階段，如果分析階段我們沒有做正確，那么設計階段我們能做正確的可能性是非常小的。
分析階段，我們得出了正確的分析產出，那么我們在設計階段，又根據合理正確的方法論，我們就可以得到合理正確的應用邏輯架構。
同時我們可以看出領域建模是抽象和架構的重要方法，但不是唯一的方法，因為歸納和演繹也是抽象及架構的重要方法，自頂向下推演也是架構的重要方法。
這套方法論的關鍵性總結應該是這樣的：
1)架構問題是我們工作中常見的問題，我們要注意識別并定義架構中的問題
2)業務概念模型的產出是通過具體的方法演繹出來的
3)業務概念架構的產出是通過具體的方法歸納出來的
4)系統模型和數據模型的產出是通過具體的方法演繹出來的
5)應用邏輯架構的產出是通過對前面的產出歸納和演繹出來的
- 架構內模塊的構建，模塊的依賴關系，及約束
- 模塊的粒度，父子模塊的歸納
- 提煉可復用模塊
- 純技術模塊的產生
- 邏輯架構的分層
- 物理架構的演進受邏輯架構的影響
- 研究業界現有的技術架構
6)應用邏輯架構推導所使用的歸納和演繹方法涉及到很多具體的知識
最重要的是這個過程是不斷迭代的，這句話比什么都重要，只有運動著的架構，沒有靜止的架構。有的架構運動時進行不斷的重構和調整，所以經久不衰，有的架構缺乏這樣的自我否定機制，最終
走向衰敗。
【本文為51CTO專欄作者“阿里巴巴官方技術”原創稿件，轉載請聯系原作者】
