完美世界辰东小说下载,将夜猫腻小说,天下高月小说

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案

架構(gòu)方法論：如何自底向上推導應用邏輯？

????

點擊閱讀上篇：??從方法到思維：什么是應用邏輯架構(gòu)的正確姿勢???

五架構(gòu)的基本約束

架構(gòu)約束分成了基本約束和業(yè)務約束：

邏輯架構(gòu)基本約束：是軟件工程領域常見的各種軟件設計原則。
邏輯架構(gòu)的職責約束：是模塊，子模塊，模型的職責相關(guān)約束，尤其是核心的模型和核心主模塊是在一定時間內(nèi)是比較穩(wěn)定的，所以此時對其定義它的約束范圍是有助于這段時間內(nèi)的研發(fā)的效率的。
各種架構(gòu)的非業(yè)務功能性約束，如穩(wěn)定性，性能，成本等等。

而本文講到的約束基本是邏輯架構(gòu)上約束，如果考慮業(yè)務約束，我們還必須要考慮我們的面向的客戶是什么群體之類的約束，如果缺少這樣的約束，在設計產(chǎn)品時可能會走偏。

5.1 常見的軟件設計原則

單一職責原則(SCP)(參考 grasp 原則)
開閉原則(OCP)
子類替換原則
依賴倒置原則(DIP)
接口隔離原則(ISP)
組合聚合復用原則(CARP)
迪米特法則(LoD)

以上這些原則都是判斷標準，那么是用什么方法論來實現(xiàn)軟件可以幫助我們的軟件符合這些原則的呢?答：設計模式。

5.2 常見設計模式

這里有兩個非常重要的關(guān)鍵詞：判斷標準 + 實現(xiàn)方法，這里判斷標準是軟件設計原則，實現(xiàn)方法設計模式。

作為一個常年在軟件行業(yè)摸爬滾打的人，設計模式和設計原則應該是較為熟悉的，或者說常用的設計模式和設計原則都是比較熟悉的。但是大部分書籍講到的是模塊內(nèi)部如何使用設計模式，并沒有重點強調(diào)邏輯架構(gòu)中模塊之間如何使用設計模式來讓邏輯架構(gòu)遵循軟件設計原則。

而我們設計或者推導邏輯架構(gòu)時，主要就是用設計模式等方法來讓邏輯架構(gòu)中的各模塊之間的關(guān)系，以及模塊內(nèi)部的子模塊之間的關(guān)系符合軟件設計原則。

5.3 關(guān)于模塊

如何用設計模式來讓模塊間的集成符合軟件設計原則，從而降低維護和擴展的成本。架構(gòu)中的模塊之間，模塊和子模塊，子模塊和子模塊要遵守軟件設計的相關(guān)約束。如何遵守呢，領域建模和設計模式是兩個具體的方法。

即使不考慮模塊之間邊界和約束，光考慮模塊內(nèi)部的設計，軟件設計原則和設計模式就已然是我們軟件工程師的必修課。再加上模塊之間的依賴或者邊界更加需要軟件設計原則和設計模式，那它們的地位就更加神圣不可替代。值得不斷的深入學習，實踐，思考和總結(jié)，這也是為設計邏輯架構(gòu)打基礎，架構(gòu)師必修課。

雖然我們一開始總是從濫用開始，不過沒關(guān)系，一開始要做到不偏不倚總是很難的，慢慢的我們就可以窺見的其中的奧妙。

5.4 具體技術(shù)在某些特定場景下的約束

這是具體的技術(shù)在某個特定場景下的約束：

Web 研發(fā)常見的規(guī)約，比如說重復提交，事務，多版本。
MySQL 的在高并發(fā)場景下的使用規(guī)約，比如說各種分庫分表的規(guī)則，索引規(guī)則等等。
高并發(fā)相關(guān)系統(tǒng)中的相關(guān)約束，比如說冪等控制，并發(fā)控制，緩存策略，線程使用，鎖粒度，各種循環(huán)內(nèi)調(diào)用遠程接口或數(shù)據(jù)庫等等。
其他。

總的來說，這里的這些約束更偏向于物理架構(gòu)上的約束，這里還是提前描述一下。同時每個物理架構(gòu)要解決的問題不一樣，導致它們要遵守的計算機科學與技術(shù)上的約束是不一樣的，這是架構(gòu)師們要整理，并倡導執(zhí)行的。

5.5 邏輯架構(gòu)中的業(yè)務屬性約束

前面講到的是軟件研發(fā)領域的基本約束，這些基本約束在高粒度模塊中一般很少被提及，高粒度模塊之間的約束關(guān)系是根據(jù)業(yè)務中的思維概念提煉而來，比如電商中提煉出訂單，營銷活動，商品等等核心概念和核心域，對這些核心概念進行定義，以確定它們之間的關(guān)系和邊界，從而形成技術(shù)上的統(tǒng)一業(yè)務約束。

同理，任何一個領域應該都存在這樣的約束，只是這樣的約束并不是一層不變的，尤其是在業(yè)務系統(tǒng)中，業(yè)務理解發(fā)生了變化，這樣的約束也會隨之變化，而且業(yè)務中約束的目的是驅(qū)動業(yè)務更好的前進的重要保障。

我們拿國家這個架構(gòu)來做簡單的解讀，讀了十年歷史，大概總結(jié)出的一個國家級別主要架構(gòu)約束是這樣的：

歷史上不同時期的國家治理有不同的架構(gòu)(三省是頂層模塊，六部是二級模塊，然后依次做模塊分解，直到一村，一戶，這戶可以看最是領域模型)和規(guī)約。西周和東周的春秋時期靠的是周公旦制作的禮和樂作為國家架構(gòu)的約束，到了戰(zhàn)國時期，禮崩樂壞，百家爭鳴，最終以統(tǒng)一國家為目標的法(這個法和保障民生的法是兩回事)成為秦國的架構(gòu)約束，得以讓他成功統(tǒng)一六國，但是很快這種法的約束又帶來了副作用，于是漢朝建立，確定孔子的儒家倫理道德作為國家架構(gòu)的主要約束。

然而這種以倫理和道德為主的架構(gòu)約束對王朝的前 100 年 - 150 年是非常有效的，但是隨著時間的發(fā)展，這樣的約束會越來越弱，約束變?nèi)鮿t利益集團會不斷的讓架構(gòu)中的模塊邊界變的模糊，有些模塊的利益變的更大，有些模塊的利益更小了，而且依賴關(guān)系變的混亂，從而使整體架構(gòu)的利益受到影響，同時由于利益牽絆太深很少有一個總架構(gòu)師有能力扭轉(zhuǎn)乾坤。最終于就會被另外一個王朝所洗牌，新的王朝會重新建立架構(gòu)，重新設定模塊間的邊界和依賴，同時還是以道德和倫理作為主要的約束。這種局面從漢朝開始周而復始了 2000 年。

不管怎么說，一個符合時宜的架構(gòu)約束是有利于架構(gòu)向前發(fā)展的，而不符合時宜的約束反而是制約者架構(gòu)發(fā)展的。各種內(nèi)耗等情況應運而生，最終阻礙了業(yè)務向前拓展。

5.6 約束小結(jié)

縱上所述，模塊間約束無處不在，技術(shù)上的約束是最最容易看懂的。越是細粒度模塊的約束，我們越容易學習和理解，比如軟件設計的原則等等，越是高粒度的模塊的約束，越抽象。需要對業(yè)務有深刻理解，對組織有深刻的理解，甚至對社會有深刻的理解。

六邏輯架構(gòu)復用

6.1 復用

件復用包含很多內(nèi)容，比如說設計的復用，文檔的復用，代碼的復用等等。在本章節(jié)中的復用特指代碼的復用。

復用的收益

提煉的目的是實現(xiàn)復用，復用的目標收益是：

軟件的研發(fā)效率的提升
研發(fā)成本下降
軟件質(zhì)量的提升
等等

復用的分類

對于復用，我從業(yè)務功能和非業(yè)務功能的角度來分了一下類，如下：

1)一種是跟業(yè)務無關(guān)的一些可復用的內(nèi)容，這些內(nèi)容存在于基礎架構(gòu)的每一個層次，但是還不能歸屬于邏輯架構(gòu)，而且業(yè)務技術(shù)無關(guān)的復用不是本文討論的重點，所以本文不會重點闡述 MVC 的設計思想是如何在不同的 Web 應用中得以復用的。

框架的復用，spring, mybatis 之類的，對于框架的研究，業(yè)界從來沒有停止過腳步
數(shù)據(jù)結(jié)構(gòu)，算法，網(wǎng)絡，等封裝庫，比如 Apache 和 Google 的各種封裝庫
中間件(RPC，Queue，cache 等)及各種存儲，監(jiān)控報警等基礎設施
ORM，IOC，AOP，MVC，BPM，Rule Engine 等等對應的框架，這些都是和業(yè)務無關(guān)的復用
等等

2)還有一種是跟業(yè)務相關(guān)的可復用內(nèi)容，它的產(chǎn)生取決于抽象能力和技術(shù)功底，比如：

系統(tǒng)模型復用：營銷活動中存在各種規(guī)則，那么這些規(guī)則應該如何抽象以達到可以被復用的程度呢?比如我們將規(guī)則中的節(jié)點可以抽象成單獨的算子，比如說滿足某個條件，執(zhí)行某個優(yōu)惠動作，那么滿足和某個優(yōu)惠動作都可以抽象成算子(在 UMP 中被稱為元數(shù)據(jù)，我們也沿襲了這一叫法)這些算子可以被復用且隨意組合，以形成新的活動規(guī)則。
流程的復用，比如每種電商平臺，都需要有交易流程，包括信息流，資金流，那么天貓，淘寶，聚劃算等的交易流程是否可以復用，如果可以應該如何復用，是否可以將相同的和不同的環(huán)節(jié)區(qū)別對待，以實現(xiàn)可復用性。
計算模型 & 框架的復用，比如說營銷中的疊加互斥計算模型，session 包的復用，特定業(yè)務中的測試框架的復用。

業(yè)務模塊復用的形式(物理架構(gòu)中要考慮的內(nèi)容)

具體的復用形式本質(zhì)上來說是物理架構(gòu)中要考慮的內(nèi)容，這里捎帶提一下。

1)二方庫形式

提煉成二方庫，誰使用誰依賴這個二方庫，這種情況又分成了兩個子類：

純邏輯，沒有數(shù)據(jù)的存儲等，其計算完全依靠調(diào)用者傳入的數(shù)據(jù)，比如說某個業(yè)務場景的規(guī)則引擎，某個業(yè)務工具包等。
有負責數(shù)據(jù)的存儲，比如說在二方庫中直連另外一個服務(也可以看做胖客戶端)，或者直接連接數(shù)據(jù)庫，這種方式在網(wǎng)站早期比較常見。

2)服務化形式

下沉成服務，通過接口對外暴露，技術(shù)手段多種多樣，比如說 HSF，SOFA 對外暴露，或者 HTTP 對外暴露等，但是這里的重點不是在使用什么樣的技術(shù)手段，而是暴露的服務中應該包含哪些內(nèi)容(有多少客戶，他們的需求的共性是什么，我們的業(yè)務本質(zhì)是什么，根據(jù)這些內(nèi)容來設計我們需要暴露的服務，然后在考慮我們接口的規(guī)范。至于使用什么樣的服務容器之類的內(nèi)容基礎設施架構(gòu)同學會重點來考量，我們需要需要學習和理解，但是我們的重點還是在前兩個，即服務到底是什么，以及服務接口的規(guī)范是什么，在這兩個上苦下功夫，對業(yè)務線的同學拿結(jié)果以及個人成長都有莫大的幫助)

3)展示組件

還有我們前端的各種可復用的展示組件的設計，比如說 TMF 的可復用組件等等。

邏輯架構(gòu)中的可復用模塊的落地表現(xiàn)形式優(yōu)劣

跟業(yè)務無關(guān)的可以復用內(nèi)容我們在本文中暫不討論，本文中我們討論一下跟業(yè)務相關(guān)的跨模塊復用的兩種情況，以及這兩種情況之間的異同：

在跟業(yè)務相關(guān)的跨模塊可復用情況中，慢慢的大家都以后者(下沉成服務)作為主要的表現(xiàn)形式，原因有便于發(fā)布，變更影響小，等等。雖然后者在調(diào)用時有一些遠程開銷，但是得益于 RPC 簡潔的二進制協(xié)議(CPU Time 的下降)和日益變小的 RTT(RT 的下降)及日益增加的帶寬，其遠程開銷的代價漸漸變得不那么顯眼，甚至可以忽視。

那么是不是后者是不是可以代替前者呢?也并不是這樣，有的場景下前者是不能用后者來代替的，比如說通過業(yè)務流程的提煉抽象而得來的業(yè)務二方庫，這個是無法通過服務化來代替的，反而這種情況下，往往是服務化+二方庫同時出現(xiàn)，起到一個很好的復用的作用。

所以在業(yè)務線的應用邏輯架構(gòu)中，復用的重點即在提煉出共同的特性(模型上，流程上，計算模型上等)，然后以二方庫或者服務化應用的方式來進行落地。那么如何在邏輯架構(gòu)中提煉出共同特性呢?

6.2 抽象和提煉

抽象和提煉基本上會從下面幾個點出發(fā)：

有類似的模型或者屬性
有類似的流程
有類似的數(shù)據(jù)結(jié)構(gòu)和算法

我相信很多人都有過這樣的經(jīng)驗。由此可見提煉就是陰陽調(diào)和：

抽象與架構(gòu)：對業(yè)務的理解，根據(jù)領域建模的方法和設計模式產(chǎn)生領域模型抽象和流程抽象，或者計算模型的抽象等等，然后根據(jù)這些抽象設計出合理的架構(gòu)，并讓架構(gòu)健康的向前迭代。
計算機科學與技術(shù)：對技術(shù)深度的把控，包括編程語言，各種框架，SDK，多線程，數(shù)據(jù)結(jié)構(gòu)，各種網(wǎng)絡編程包，各種 xx 引擎(如規(guī)則引擎，流程引擎等等)。

而這些都需要工程師們對領域建模和設計模式的抽象技術(shù)，以及對相對的技術(shù)特性等計算機技術(shù)的深入掌握。這里需要強調(diào)光知道領域建模和設計模式等是不夠的，不同的技術(shù)選型特性不一樣，會導致在抽象的實現(xiàn)時產(chǎn)生不同的差別。

在復用這件事情上，抽象技術(shù)和計算機技術(shù)兩手抓，兩手都要硬。如果用中國古代傳統(tǒng)思想來比喻，那可能可以用陰來比喻抽象技術(shù)，陽來比喻計算機技術(shù)。尤其是陰，總是給人捉摸不定的感覺，但是如何深入學習，堅持實踐總結(jié)，我們就會發(fā)現(xiàn)陰原來也是有具體方法論的，但是這個具體方法又不是看看書就能學會的，它對知行合一的要求更高。

從學習的步驟來說，一般的過程都是先從陽(計算機科學與技術(shù))開始，因為先從陰(抽象和架構(gòu)技術(shù))開始沒有陽作為支撐是很難把陰融會貫通的。而且最終要達到的是陰陽調(diào)和。如果我們過于偏重陰或者過于偏重陽，都會導致陰陽失調(diào)，大概就是這個意思。

來到數(shù)據(jù)部門之后，我發(fā)現(xiàn)已經(jīng)不能用陰陽來形容我們要學的領域了，現(xiàn)在我們搞的比較多的是統(tǒng)計分析和機器學習(統(tǒng)計分析和機器學習有交集，也有區(qū)別)，所以目前對我們團隊來說，我們的同學有三門學科是必須要掌握的：

計算機科學與技術(shù)
抽象與架構(gòu)
統(tǒng)計分析與機器學習

我最近一年看的比較多的是統(tǒng)計分析，有同學釘釘我問道：怎么連你也放棄領域建模了。我沒放棄，領域建模是抽象和架構(gòu)的重要方法(但不是唯一的方法，演繹和歸納也是，自頂向下分解也是)，工程技術(shù)同學是不能放棄的。學習統(tǒng)計分析及統(tǒng)計學習是因為統(tǒng)計學習 + 計算機科學與技術(shù)可以更好的解決工程領域遇到的問題，這也是各條線的工程師需要掌握的技能。

6.3 復用小結(jié)

復用是軟件中一個非常重要的學問，里面結(jié)合了抽象技術(shù)和計算機技術(shù)，而抽象技術(shù)還依賴于對業(yè)務的理解程度，所以此非一日之功，需要長時間的鍛煉才能有所小成。

當然，有時候即使在技術(shù)上可以抽象提煉，但是由于組織架構(gòu)的問題也會讓這樣的提煉無法落地，或者這里并不是一個穩(wěn)定的結(jié)構(gòu)從而導致經(jīng)常調(diào)整，帶來的結(jié)果是提煉的投入產(chǎn)出比比較小，從而導致無法提煉，這些這里就不詳細寫了。

七邏輯架構(gòu)分層

7.1 分層的分類

工程骨架分層

分層幾乎是從每個工程師入門的時候都會接觸到的一個普世的概念，在一些書籍里，分層有的被稱之為 tier，有的被稱之為 layer，比如說 OSI 分層模型是用的 Layer 這個詞。而在一些文章里講到架構(gòu)時用的是 tier 這個詞，當你去查看 wiki 的時候，那就更暈了，因為 wiki 離 tier 和 layer 是混在一起講的。

談到分層，各種教科書中分層無不拿出景點的 3 個層次來闡述分層問題，如下：

presentation layer
business layer
data layer

然后還有擴展出 service layer，這些在工程骨架中非常常見，我們幾乎從來沒有見過不分層的工程骨架，所以當我們討論架構(gòu)分層的時候，很多人腦海里第一映像就是工程骨架中的分層。

工程骨架的分層的一個重要目的是：成為代碼組織結(jié)構(gòu)的約束，防止代碼混亂不堪。

邏輯架構(gòu)分層

但是我們講的邏輯架構(gòu)分層不是指工程骨架分層，為什么不是?首先來看一下邏輯架構(gòu)的特點：

源于業(yè)務概念架構(gòu)(源于業(yè)務分析)，保留了業(yè)務概念架構(gòu)中大多數(shù)的業(yè)務功能模塊，但是又會通過對技術(shù)的提煉從而比業(yè)務概念架構(gòu)更加復雜。
邏輯架構(gòu)中上下左右模塊之間存在依賴關(guān)系，所以確定模塊依賴關(guān)系是一個非常重要的話題。
邏輯架構(gòu)是分片的，一般來說同一個層次會存在多個模塊，像兄弟一樣。

根據(jù)這個特點，我們可以模糊的看出邏輯架構(gòu)的分層主要是邏輯架構(gòu)中各模塊的調(diào)用關(guān)系，甚至更偏向從模塊職責的角度來進行歸納從而得出層次。

這種分層的目的是：對同一類職責的模塊進行職責上的約束，此時還不一定有代碼的存在。

兩者的區(qū)別

這么看來這兩個分層是有著本質(zhì)的區(qū)別：

目的上：邏輯架構(gòu)中的分層是邏輯架構(gòu)中各模塊間的依賴層次關(guān)系，以及模塊的再抽象。而項目骨架中的分層是代碼的組織形式的一種約束。
形式上：某個邏輯架構(gòu)中某個層次上的應用內(nèi)部依然是存在工程骨架分層的，比如說購物車模塊依賴了營銷模塊和商品模塊，他們在邏輯架構(gòu)上可能是不同的層次，但是購物車，營銷內(nèi)部的工程骨架上依然進行presentation， business, repository 之類的分層。

也許有的同學會說了，再大的架構(gòu)(就比如說某個 BU 的邏輯架構(gòu))，我也可以將最靠近用戶的模塊劃分成 presentation layer，中間的所有模塊都劃分為 business layer，最下面的我都劃分成 presentation layer。沒錯，你可以這樣做，但是這樣做基本沒有任何意義，不能帶來指導作用，失去的分層的目的。

7.2 分層的案例

在文件系統(tǒng)或者網(wǎng)絡協(xié)議上，也有各種層次的封裝。如下圖所示：

這個圖中每個模塊在不同階段都有不同階段要解決的問題，然后每個模塊都可以分解，產(chǎn)生更細粒度的模塊，這里重點是讓大家了解到什么是邏輯架構(gòu)中模塊的分層。

宏觀上來看，處于上層的模塊會依賴處于下層的模塊
同一層的模塊有時候也會產(chǎn)生依賴關(guān)系
在層次上可以用箭頭標注數(shù)據(jù)流或者調(diào)用流

不過這些都不是問題，問題是什么呢?

問題是我們必須時刻知道，目前我們在不同層次的這些模塊存在哪些問題，以及不同層次在解決什么問題。比如說上述的操作系統(tǒng)中文件系統(tǒng)和協(xié)議分層中，最底層的是跟硬件打交道，能夠精準的控制硬件，中間是對操作系統(tǒng)的用戶暴露的，更簡單易用，上層是針對應用來使用，解決特定領域的問題，不同的層次做了不同的抽象，也是在解決不同的問題。

7.3 某些領域建模書籍之中的分層

很多人及一些書中，談分層必談工程骨架的分層，這個分層和架構(gòu)中的分層是兩回事，如果我們在談架構(gòu)，那么我們要避免把重心放到項目骨架的分層上。

比如說領域建模的相關(guān)書籍中，經(jīng)常會講到 service, domain, repository 之流，這個些概念處于架構(gòu)中的什么位置，我們應該什么時候去關(guān)心這些概念?

如圖所示，在細粒度模塊內(nèi)部，按照純技術(shù)職責來進行劃分時，我們將之擼成 service, model, repository,integration 之流的工程骨架，值得注意的是工程骨架的劃分層次和具體的業(yè)務邏輯架構(gòu)是沒有關(guān)系的，他更偏技術(shù)，他的職責是對代碼做一個高層次的組織和管理。

按照正常流程，系統(tǒng)模型產(chǎn)出之后，應該緊接著考慮模塊的設定，依賴，規(guī)約，但是很不幸，很多書籍和資料都把 service, model, repository,integration 這部分分層的內(nèi)容作為了領域的建模的最重要的重點之一。

某些書里的這種觀點是不符合實際工作流程的，實際工作時，在領域模型之后我們先考慮的是架構(gòu)中的各個模塊的位置和職責，以及模塊內(nèi)部的子模塊，模塊之間的關(guān)系，以及整體的約束等等(請參考文章開頭對架構(gòu)的定義)。具體表現(xiàn)就是我們在邏輯架構(gòu)圖中不會去畫什么 service, model, repository, integration 之類的層。

工程骨架的分層在細粒度模塊內(nèi)部，這是基礎設施架構(gòu)的一部分，也許是你手頭目前最重要的部分，但是對于整個應用邏輯架構(gòu)來說不是最核心的部分也不是最需要先考慮的內(nèi)容。也就是說，即使你不分 service, model 之類的，對應用邏輯架構(gòu)中模塊的職責劃分也是沒有影響的。

同時我也見過一些項目，應用邏輯架構(gòu)比較明確了，但是在落地到物理架構(gòu)時，把邏輯架構(gòu)中的所有模塊都放在 service 包里，而且沒有再分包，這就不合適了，邏輯架構(gòu)中的模塊完全沒有落地。

所以我現(xiàn)在在我們部門的項目中，堅決避免將 service, model, repository,integration 之類的放到最高層來考慮。而是將邏輯架構(gòu)的設計切切實實的落地，這樣根據(jù)邏輯架構(gòu)，我們就能看到的我們具體的應用，和應用內(nèi)包的組織情況。

再次強調(diào)：邏輯架構(gòu)中的分層不是指 service, model,repository, integration 之流的分層，而是指功能模塊的分層。如果不了解業(yè)務，如果不了解業(yè)務概念模塊，如果沒有業(yè)務概念架構(gòu)，我們是很難做出合理的應用邏輯架構(gòu)的(當然也包括邏輯架構(gòu)中模塊的分層)，撇開業(yè)務特征直接談邏輯架構(gòu)的分層是不行的。

模塊的職責確定之后，模塊之間的依賴也必須要確定，然后模塊對外暴露接口需要定義規(guī)范和技術(shù)實現(xiàn)的手段。比如，如果是 restful 接口，那么應該是什么樣的規(guī)范對外定義，如果是內(nèi)部的服務的接口，應該是什么樣的規(guī)范。由于本文篇幅所限，此處不進行詳述，前者可參考各大平臺的開放接口，后者可參考各 BU 內(nèi)部服務調(diào)用的相關(guān)規(guī)范，如果沒有，那說需要制定一個統(tǒng)一的規(guī)范。

八邏輯架構(gòu)是分粒度的

8.1 邏輯架構(gòu)顆粒度樹

這里我引入了一個新概念：邏輯架構(gòu)顆粒度樹。

剛剛講的都是 2 維上的架構(gòu)，我們可以看到，架構(gòu)推導是有方法的，而且如果對方法進行提煉，就是橫和豎的問題，但是正如我們開始講到的，架構(gòu)也可以是 3 維的，那就是在二維的模塊中存在各種粒度子模塊或者父模塊。

如果非要打個比喻的話，那么下面的宇宙星神合體是一個大的架構(gòu)：

里面分成了很多小模塊，比如物質(zhì)飛船，探測器等等，而每個小模塊又是有很多基礎模塊構(gòu)成，宇宙星神合體中只有 3 個層次，及基礎部件，模塊，及最終的星神合體，它們代表著不同的粒度。而對于業(yè)務復雜的架構(gòu)來說，粒度會更多，層次就會更多。這取決于N個研發(fā)資源投入在某個模塊上的效率最高，而這個 N 在某個階段的技術(shù)限制下應該是一個比較穩(wěn)定的值!

抽象一下，模塊在不同粒度上，可以整成這么一棵樹：

邏輯架構(gòu)粒度樹的 3 條原則：

縱向上，任何一層次的模塊的職責，都必須是下一層職責的概括
橫向上，同一層次的模塊職責屬于同一范疇
橫向上，同一層次的模塊的邊界清晰

上述的樹形結(jié)構(gòu)，只能描繪出模塊和父模塊，子模塊的關(guān)系，但是不能完整的描繪出模塊之間的關(guān)系，是處于同一層次，還是處在不同層次(就是前面提到的應用邏輯架構(gòu)中橫的問題和豎的問題)。

那么用什么樣的圖形既可以生動的表達出模塊和父模塊，及子模塊的關(guān)系，又能表達出不同模塊之間的關(guān)系呢，我想了很久，也沒有想到一個更容易理解的圖形，最后產(chǎn)出了下面這么一幅圖：

圖中有三層，但是現(xiàn)實生活中可能超過三層，也可能低于三層。我們能歸納的層次越高，那可能我們接觸的東西就越寬廣，越精深。

這里有一個嚴肅的話題需要提一下：是不是一線工程師不用考慮邏輯架構(gòu)問題?當然不是，任何一個同學，你手頭的工作都是跟架構(gòu)相關(guān)的，你負責模塊可能也存在子模塊，而且必定會存在父模塊，出于工作，你必須要理解不斷迭代你模塊中的設計，同時隨著能力的成長，你必須要關(guān)注你的父模塊，父模塊的父模塊，日積月累，你可以 hold 住的模塊粒度會越來越大，你的職責和能力要求會越來越大。

8.2 模塊顆粒度樹落地情況

在下述架構(gòu)模塊顆粒度樹中，并沒有模塊和模塊之間的依賴關(guān)系，這里只是為了概要的說明模塊落地到物理架構(gòu)中的一個演變過程，而具體的案例我們放在后面的文章中來進行闡述。

模塊樹上的這些不同粒度的模塊，在具體落地成物理架構(gòu)時，可以是不同的形式，如下：

可能是子包
可能是頂層的包
可能是應用
可能是一組應用的集合，負責某種職責
也可能是某個平臺(如營銷平臺，商品中心等)
更有可能更大層次的平臺，比如 B2C

為什么會出現(xiàn)這種情況呢，因為不同的模塊在業(yè)務的發(fā)展的不同時期：

模塊中的邏輯的復雜度不一樣
模塊的粒度本身也在發(fā)生變化

那么我們來看看一個網(wǎng)站從小到大的邏輯架構(gòu)模塊樹落地的變化情況。

小型業(yè)務邏輯架構(gòu)的模塊樹落地情況

很顯然，這里是一個電商網(wǎng)站起步時候的樣子，所有模塊都有模有樣，只是模塊中的邏輯比較簡單，這些模塊都以包的形式存在于一個應用之中，這個應用是一個大泥球。但是由于模塊的職責劃分合理，粒度的治理也比較符合發(fā)展要求，所以這樣的應用在分拆成分布式的時候阻力會比較小。而那些模塊職責不合理的大泥球應用，隨著業(yè)務的發(fā)展，要分拆成分布式應用，阻力就大很多。

中型業(yè)務邏輯架構(gòu)的模塊樹落地情況

這是一個度過初期階段的電商網(wǎng)站，營銷，商品，交易模塊等已經(jīng)成型，而且得益之前的模塊劃分，架構(gòu)師可以很快的將初期的多個頂級包，分拆出來，變成多個應用。

大型業(yè)務邏輯架構(gòu)的模塊樹落地情況

到了這個時期，已經(jīng)是一個大型電商網(wǎng)站的樣子了，營銷平臺內(nèi)部已經(jīng)分拆出了多個應用，得益于上一階段中各模塊職責的合理分配，所以架構(gòu)師將在將物理架構(gòu)進化成這個樣子的時候，力氣不需要花在邏輯架構(gòu)的治理上，可以把精力集中投入到物理架構(gòu)及基礎設施架構(gòu)的建設上，比如同城容災，異地多活等等。

8.3 再發(fā)展成巨型的架構(gòu)呢?

中臺概念抽象

我不知道，比如中臺是不是，要把電商業(yè)務中所有的相對穩(wěn)定的核心抽象出來，可能是領域模型，可能是業(yè)務流程轉(zhuǎn)換而成的系統(tǒng)流程，可能是一個計算模型或者算法等等。然后變化的內(nèi)容(前臺)可以依托于這個大的核心概念快速的迭代。如果需要圖形化來做概要的理解，我想應該是這樣的：

一旦要做一個中臺，那么以為著這個中臺對前臺來說就是一個技術(shù)產(chǎn)品，則要考慮如下幾個方面的內(nèi)容：

穩(wěn)定性性能的要求是極高的，需要有體系化穩(wěn)定性和性能體系
產(chǎn)品運營是非常重要的，到售前，到售后有一個完整的流程

目的就是要提高客戶的生產(chǎn)效率。

是否存在中臺的判斷依據(jù)是什么?

多個業(yè)務線有無重復的流程抽象，有無重復的領域模型抽象，有無重復的計算模型(數(shù)據(jù)結(jié)構(gòu)和算法)等等，有無重復的輔助性設施。他們是否在重復建設，等等。

在演變的過程中變化是什么呢?需要的是學習能力，溝通能力，協(xié)調(diào)資源的能力，領導力，影響力，評估人的能力和用人的能力等等。這些能力需要涉及的范圍都從一個小的組織向一個更大的組織前進。

大音希聲，大象無形，不管如何發(fā)展，基礎的規(guī)律都還是不變的。

8.4 邏輯模塊落地的相關(guān)考量維度

當一個邏輯模塊要落地時，我們?nèi)绾闻袛嘁粋€模塊落地成包，還是應用等等，有很多判斷的維度，比如：

效率(多少人維護一個應用效率最高)

到底多少人的團隊協(xié)作效率最高?作為一個應用，在技術(shù)不斷進步的情況下(比如說新的容器之類的)，或者要面對的業(yè)務的復雜度不同的情況下，同時可維護的人數(shù)也是不一樣的，具體目前變化到多少，目前基本是靠經(jīng)驗，然后遇到問題再調(diào)整，根據(jù)主管的經(jīng)驗不斷調(diào)整和優(yōu)化，以達到一個適合當前階段的最優(yōu)值，目前我自己這邊大概5人左右一個攻堅小組，遇到更大問題域，那就拆解。

穩(wěn)定性

強弱依賴
核心與非核心分離

性能

QPS，包括模塊內(nèi)部的技術(shù)實現(xiàn)，是使用多線程還是協(xié)程，容量評估，到壓測，等等，里面大量的內(nèi)容。光是線程這一節(jié)就有需要研究很久最大 QPS 推導及同步異步問題：
RT，減少 wait time? 減少 cpu time?從瀏覽器，到網(wǎng)絡，到服務器，到存儲等每個環(huán)節(jié)，比如說網(wǎng)絡上有一個重要的公式：BDP = BD * RTT，把這個公式背后的相關(guān)知識點搞清楚，那么網(wǎng)絡優(yōu)化的很多方法的理論依據(jù)我們就搞清楚了。

這里面，效率，穩(wěn)定性，性能是最影響邏輯架構(gòu)落地成物理架構(gòu)的三大主要因素。

九全文總結(jié)

9.1 架構(gòu)的定義和價值

我們在文章的開頭對架構(gòu)兩個字給出了一個官方定義，然后按照筆者自己對架構(gòu)的理解又對架構(gòu)進行了分類，在架構(gòu)分類中，出現(xiàn)了產(chǎn)品功能架構(gòu)，業(yè)務架構(gòu)，應用邏輯架構(gòu)，應用物理架構(gòu)等等。

不同的架構(gòu)都是在解釋不同的問題，比如：

產(chǎn)品功能架構(gòu)強調(diào)的是功能模塊能力，受眾是最終使用產(chǎn)品的用戶等。
業(yè)務架構(gòu)是對業(yè)務的一種分析和理解，用來如何更好的構(gòu)建產(chǎn)品，受眾是產(chǎn)品的同學和技術(shù)同學。
應用邏輯架構(gòu)強調(diào)的是研發(fā)時，各邏輯模塊的職責，受眾是研發(fā)的同學及架構(gòu)師。

正確分析出當前的場合(受眾和目的)應該用什么樣的架構(gòu)來闡述我們的意圖是非常重要的。

同時我們可以看到小到一個mis系統(tǒng)，大到整個阿里，都可以用架構(gòu)的角度來解釋，架構(gòu)中出現(xiàn)的各種中臺，后臺，各種框架等等其實都是架構(gòu)方法產(chǎn)出的結(jié)果。系統(tǒng)大小不一樣，抽象的方法是類似的。

架構(gòu)產(chǎn)生之后，隨著業(yè)務的迭代，架構(gòu)不治理，模塊職責和依賴，層次不清晰，約束不明確。穩(wěn)定性，性能，成本都受到影響。積弊越久，回頭越難，有時候不得不重頭來過。

9.2 自底向上重度依賴于演繹和歸納

為了避免推倒重造的問題發(fā)生，我們需要不斷的自底向上的方式來修正架構(gòu)，修正其實是在做局部的模塊重構(gòu)，談到修正，具體的方法是由這里就不得正視歸納和演繹的重要性了，而這里的演繹和歸納是抽象的核心概括。

自底向上的推導的重點在于演繹和歸納，越是底層的越是要使用演繹的方法，越是高層的越是使用歸納。

這兩種方法應該什么時候使用?顯然當我們的目標(比如說業(yè)務目標)或者結(jié)論是非常高粒度的時候，需要分解，那么使用自頂向下的推導，在規(guī)劃未來時一般會用到類似的自頂向下的方法，產(chǎn)出我們宏觀結(jié)論。

而如果是產(chǎn)品方案已經(jīng)明確，程序員需要理解這個業(yè)務需求，并根據(jù)產(chǎn)品方案推導出架構(gòu)，此時一般使用自底向上的方法，而領域建模就是這種自底向上的分析方法。

對于自底向上的分析方法，如果提煉一下關(guān)鍵詞，會得到如下兩個關(guān)鍵詞：

演繹

演繹就是邏輯推導，越是底層的，越需要演繹：

從用例到業(yè)務模型就屬于演繹
從業(yè)務模型到系統(tǒng)模型也屬于演繹
根據(jù)目前的問題，推導出要實施某種穩(wěn)定性措施，這是也是演繹

歸納

這里的歸納是根據(jù)事物的某個維度來進行歸類，越是高層的，越需要歸納：

問題空間模塊劃分屬于歸納
邏輯架構(gòu)中有部分也屬于歸納
根據(jù)一堆穩(wěn)定性問題，歸納出，事前，事中，事后都需要做對應的操作，是就是根據(jù)時間維度來進行歸納。

關(guān)于歸納，我們前面已經(jīng)做了大量的講解，所以這里我們重點闡述一下演繹：

1)我們從對業(yè)務的理解，演繹出用例，從用例演繹抽象出業(yè)務概念模型，從業(yè)務概念演繹抽象出系統(tǒng)模型，從系統(tǒng)模型演繹抽象出物理存儲模型。這是一個從 A 推導出 B，從 B 推導出 C，從 C 推導出 D，從 D 推導出E的過程，而在 B，C，D 上又有很多邏輯分支。推導出的層次越深，邏輯分支越廣(保障每層的準確度的基礎上)，一般來說實力越強。

2)我們從對業(yè)務的理解，演繹出用例，從用例演繹出業(yè)務流程，再從業(yè)務流程演繹抽象成系統(tǒng)流程，然后再演繹成數(shù)據(jù)流。這是也是一個從 A 推導出 B，從 B 推導出 C'，從 C' 推導成 D'，從 D' 推導出 E' 的過程。這個推導過程比如有方法論輔助，否則邏輯的深度和廣度都會受到影響。

總的來說：演繹推導的層次越深，分支邏輯越多，越能穿透迷霧，看問題就越透徹，說明功力越深厚。

打個比喻就是：對應相同品種的樹來說，小樹的根系和大樹的根系在地下深入的長度和廣度是完全不一樣的，人的邏輯能力大抵也是如此。

其實我們工作中很多時候都在使用演繹和歸納，只是我們不知道我們在使用這類方法，看到這篇文章之后也許可以給大家?guī)ヒ恍┧伎迹辞宄覀冏约阂郧暗墓ぷ鞯降资侨绾问褂醚堇[和歸納的，以及如何改進以前的方法。

9.3 邏輯架構(gòu)的自底向上推演

除了自底向上的通用思考方法之外，我們還必須要了解計算機領域的相關(guān)技能和套路才能產(chǎn)出合適的結(jié)果：

這張圖是有嚴密的邏輯路徑的，每個步驟的輸入，都是上個步驟的輸出。更關(guān)鍵的是這個張圖是有順序的，做架構(gòu)要從上往下做，不可自顧自，不可撇開業(yè)務閉門造車。

為什么前面我們問題空間領域模型聊了這么多，原因就是問題空間的領域建模其實是分析階段，如果分析階段我們沒有做正確，那么設計階段我們能做正確的可能性是非常小的。

分析階段，我們得出了正確的分析產(chǎn)出，那么我們在設計階段，又根據(jù)合理正確的方法論，我們就可以得到合理正確的應用邏輯架構(gòu)。

同時我們可以看出領域建模是抽象和架構(gòu)的重要方法，但不是唯一的方法，因為歸納和演繹也是抽象及架構(gòu)的重要方法，自頂向下推演也是架構(gòu)的重要方法。

這套方法論的關(guān)鍵性總結(jié)應該是這樣的：

1)架構(gòu)問題是我們工作中常見的問題，我們要注意識別并定義架構(gòu)中的問題

2)業(yè)務概念模型的產(chǎn)出是通過具體的方法演繹出來的

3)業(yè)務概念架構(gòu)的產(chǎn)出是通過具體的方法歸納出來的

4)系統(tǒng)模型和數(shù)據(jù)模型的產(chǎn)出是通過具體的方法演繹出來的

5)應用邏輯架構(gòu)的產(chǎn)出是通過對前面的產(chǎn)出歸納和演繹出來的

架構(gòu)內(nèi)模塊的構(gòu)建，模塊的依賴關(guān)系，及約束
模塊的粒度，父子模塊的歸納
提煉可復用模塊
純技術(shù)模塊的產(chǎn)生
邏輯架構(gòu)的分層
物理架構(gòu)的演進受邏輯架構(gòu)的影響
研究業(yè)界現(xiàn)有的技術(shù)架構(gòu)

6)應用邏輯架構(gòu)推導所使用的歸納和演繹方法涉及到很多具體的知識

最重要的是這個過程是不斷迭代的，這句話比什么都重要，只有運動著的架構(gòu)，沒有靜止的架構(gòu)。有的架構(gòu)運動時進行不斷的重構(gòu)和調(diào)整，所以經(jīng)久不衰，有的架構(gòu)缺乏這樣的自我否定機制，最終

走向衰敗。

【本文為專欄作者“阿里巴巴官方技術(shù)”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】

??戳這里，看該作者更多好文??

當前文章：架構(gòu)方法論：如何自底向上推導應用邏輯？
網(wǎng)站路徑：http://fisionsoft.com.cn/article/dhoicoe.html

新聞中心

其他資訊