原標(biāo)題：架構(gòu)方法論：如何自底向上推導(dǎo)應(yīng)用邏輯？

導(dǎo)讀：上周我們分享了本文的上篇，討論了什么是架構(gòu)、架構(gòu)的兩種推導(dǎo)思路以及自底向上的架構(gòu)方法。今天繼續(xù)分享架構(gòu)的基本約束、邏輯架構(gòu)復(fù)用及分層的問題。本文較長，同學(xué)們可收藏后再看。

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

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

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

• 邏輯架構(gòu)基本約束：是軟件工程領(lǐng)域常見的各種軟件設(shè)計原則。

• 邏輯架構(gòu)的職責(zé)約束：是模塊，子模塊，模型的職責(zé)相關(guān)約束，尤其是核心的模型和核心主模塊是在一定時間內(nèi)是比較穩(wěn)定的，所以此時對其定義它的約束范圍是有助于這段時間內(nèi)的研發(fā)的效率的。

• 各種架構(gòu)的非業(yè)務(wù)功能性約束，如穩(wěn)定性，性能，成本等等。

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

5.1常見的軟件設(shè)計原則

1. 單一職責(zé)原則（SCP）（參考grasp原則）
2. 開閉原則（OCP）
3. 子類替換原則
4. 依賴倒置原則（DIP）
5. 接口隔離原則（ISP）
6. 組合聚合復(fù)用原則（CARP）
7. 迪米特法則（LoD）

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

5.2常見設(shè)計模式

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

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

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

5.3關(guān)于模塊

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.6約束小結(jié)

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

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

6.1復(fù)用

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

復(fù)用的收益

提煉的目的是實(shí)現(xiàn)復(fù)用，復(fù)用的目標(biāo)收益是：

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

復(fù)用的分類

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

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

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

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

• 系統(tǒng)模型復(fù)用：營銷活動中存在各種規(guī)則，那么這些規(guī)則應(yīng)該如何抽象以達(dá)到可以被復(fù)用的程度呢？比如我們將規(guī)則中的節(jié)點(diǎn)可以抽象成單獨(dú)的算子，比如說滿足某個條件，執(zhí)行某個優(yōu)惠動作，那么滿足和某個優(yōu)惠動作都可以抽象成算子（在UMP中被稱為元數(shù)據(jù)，我們也沿襲了這一叫法）這些算子可以被復(fù)用且隨意組合，以形成新的活動規(guī)則。

• 流程的復(fù)用，比如每種電商平臺，都需要有交易流程，包括信息流，資金流，那么天貓，淘寶，聚劃算等的交易流程是否可以復(fù)用，如果可以應(yīng)該如何復(fù)用，是否可以將相同的和不同的環(huán)節(jié)區(qū)別對待，以實(shí)現(xiàn)可復(fù)用性。

• 計算模型&框架的復(fù)用，比如說營銷中的疊加互斥計算模型，session包的復(fù)用，特定業(yè)務(wù)中的測試框架的復(fù)用。

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

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

1）二方庫形式

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

• 純邏輯，沒有數(shù)據(jù)的存儲等，其計算完全依靠調(diào)用者傳入的數(shù)據(jù)，比如說某個業(yè)務(wù)場景的規(guī)則引擎，某個業(yè)務(wù)工具包等。

• 有負(fù)責(zé)數(shù)據(jù)的存儲，比如說在二方庫中直連另外一個服務(wù)（也可以看做胖客戶端），或者直接連接數(shù)據(jù)庫，這種方式在網(wǎng)站早期比較常見。

2）服務(wù)化形式

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

3）展示組件

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

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

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

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

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

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

6.2抽象和提煉

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

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

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

• 抽象與架構(gòu)：對業(yè)務(wù)的理解，根據(jù)領(lǐng)域建模的方法和設(shè)計模式產(chǎn)生領(lǐng)域模型抽象和流程抽象，或者計算模型的抽象等等，然后根據(jù)這些抽象設(shè)計出合理的架構(gòu)，并讓架構(gòu)健康的向前迭代。

• 計算機(jī)科學(xué)與技術(shù)：對技術(shù)深度的把控，包括編程語言，各種框架，SDK，多線程，數(shù)據(jù)結(jié)構(gòu)，各種網(wǎng)絡(luò)編程包，各種xx引擎（如規(guī)則引擎，流程引擎等等）。

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

在復(fù)用這件事情上，抽象技術(shù)和計算機(jī)技術(shù)兩手抓，兩手都要硬。如果用中國古代傳統(tǒng)思想來比喻，那可能可以用陰來比喻抽象技術(shù)，陽來比喻計算機(jī)技術(shù)。

尤其是陰，總是給人捉摸不定的感覺，但是如何深入學(xué)習(xí)，堅持實(shí)踐總結(jié)，我們就會發(fā)現(xiàn)陰原來也是有具體方法論的，但是這個具體方法又不是看看書就能學(xué)會的，它對知行合一的要求更高。

從學(xué)習(xí)的步驟來說，一般的過程都是先從陽（計算機(jī)科學(xué)與技術(shù)）開始，因?yàn)橄葟年帲ǔ橄蠛图軜?gòu)技術(shù)）開始沒有陽作為支撐是很難把陰融會貫通的。而且最終要達(dá)到的是陰陽調(diào)和。如果我們過于偏重陰或者過于偏重陽，都會導(dǎo)致陰陽失調(diào)，大概就是這個意思。

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

1. 計算機(jī)科學(xué)與技術(shù)
2. 抽象與架構(gòu)
3. 統(tǒng)計分析與機(jī)器學(xué)習(xí)

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

6.3復(fù)用小結(jié)

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

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

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

7.1分層的分類

工程骨架分層

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

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

1. presentationlayer
2. businesslayer
3. datalayer

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

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

邏輯架構(gòu)分層

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

• 源于業(yè)務(wù)概念架構(gòu)（源于業(yè)務(wù)分析），保留了業(yè)務(wù)概念架構(gòu)中大多數(shù)的業(yè)務(wù)功能模塊，但是又會通過對技術(shù)的提煉從而比業(yè)務(wù)概念架構(gòu)更加復(fù)雜。

• 邏輯架構(gòu)中上下左右模塊之間存在依賴關(guān)系，所以確定模塊依賴關(guān)系是一個非常重要的話題。

• 邏輯架構(gòu)是分片的，一般來說同一個層次會存在多個模塊，像兄弟一樣。

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

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

兩者的區(qū)別

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

• 目的上：邏輯架構(gòu)中的分層是邏輯架構(gòu)中各模塊間的依賴層次關(guān)系，以及模塊的再抽象。而項目骨架中的分層是代碼的組織形式的一種約束。

• 形式上：某個邏輯架構(gòu)中某個層次上的應(yīng)用內(nèi)部依然是存在工程骨架分層的，比如說購物車模塊依賴了營銷模塊和商品模塊，他們在邏輯架構(gòu)上可能是不同的層次，但是購物車，營銷內(nèi)部的工程骨架上依然進(jìn)行presentation，business,repository之類的分層。

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

7.2分層的案例

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

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

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

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

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

7.3某些領(lǐng)域建模書籍之中的分層

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. 縱向上，任何一層次的模塊的職責(zé)，都必須是下一層職責(zé)的概括
2. 橫向上，同一層次的模塊職責(zé)屬于同一范疇
3. 橫向上，同一層次的模塊的邊界清晰

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

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

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

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

8.2模塊顆粒度樹落地情況

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

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

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

為什么會出現(xiàn)這種情況呢，因?yàn)椴煌哪K在業(yè)務(wù)的發(fā)展的不同時期：

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

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

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

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

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

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

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

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

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

中臺概念抽象

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

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

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

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

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

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

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

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

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

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

效率（多少人維護(hù)一個應(yīng)用效率最高）

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

穩(wěn)定性

• 強(qiáng)弱依賴
• 核心與非核心分離

性能

• QPS，包括模塊內(nèi)部的技術(shù)實(shí)現(xiàn)，是使用多線程還是協(xié)程，容量評估，到壓測，等等，里面大量的內(nèi)容。光是線程這一節(jié)就有需要研究很久最大QPS推導(dǎo)及同步異步問題：

• RT，減少waittime?減少cputime？從瀏覽器，到網(wǎng)絡(luò)，到服務(wù)器，到存儲等每個環(huán)節(jié)，比如說網(wǎng)絡(luò)上有一個重要的公式：BDP=BD*RTT，把這個公式背后的相關(guān)知識點(diǎn)搞清楚，那么網(wǎng)絡(luò)優(yōu)化的很多方法的理論依據(jù)我們就搞清楚了。

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

九全文總結(jié)

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

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

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

• 產(chǎn)品功能架構(gòu)強(qiáng)調(diào)的是功能模塊能力，受眾是最終使用產(chǎn)品的用戶等。

• 業(yè)務(wù)架構(gòu)是對業(yè)務(wù)的一種分析和理解，用來如何更好的構(gòu)建產(chǎn)品，受眾是產(chǎn)品的同學(xué)和技術(shù)同學(xué)。

• 應(yīng)用邏輯架構(gòu)強(qiáng)調(diào)的是研發(fā)時，各邏輯模塊的職責(zé)，受眾是研發(fā)的同學(xué)及架構(gòu)師。

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

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

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

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

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

自底向上的推導(dǎo)的重點(diǎn)在于演繹和歸納，越是底層的越是要使用演繹的方法，越是高層的越是使用歸納。

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

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

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

演繹

演繹就是邏輯推導(dǎo)，越是底層的，越需要演繹：

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

歸納

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

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

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

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

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

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

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

其實(shí)我們工作中很多時候都在使用演繹和歸納，只是我們不知道我們在使用這類方法，看到這篇文章之后也許可以給大家?guī)ヒ恍┧伎?，看清楚我們自己以前的工作到底是如何使用演繹和歸納的，以及如何改進(jìn)以前的方法。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PS：由于我架構(gòu)水平，寫作水平，及認(rèn)知所限，有很多我自己都不知道自己不知道的規(guī)律和事實(shí)存在。所以文中整體思路和細(xì)節(jié)之處不免存在紕漏之處，還望大家不吝指出，謝謝。