┊文章閱讀:次
原標(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)上約束,如果考慮業(yè)務(wù)約束,我們還必須要考慮我們的面向的客戶是什么群體之類的約束,如果缺少這樣的約束,在設(shè)計(jì)產(chǎn)品時(shí)可能會(huì)走偏。
5.1常見的軟件設(shè)計(jì)原則
以上這些原則都是判斷標(biāo)準(zhǔn),那么是用什么方法論來實(shí)現(xiàn)軟件可以幫助我們的軟件符合這些原則的呢?答:設(shè)計(jì)模式。
5.2常見設(shè)計(jì)模式
這里有兩個(gè)非常重要的關(guān)鍵詞:判斷標(biāo)準(zhǔn)+實(shí)現(xiàn)方法,這里判斷標(biāo)準(zhǔn)是軟件設(shè)計(jì)原則,實(shí)現(xiàn)方法設(shè)計(jì)模式。
作為一個(gè)常年在軟件行業(yè)摸爬滾打的人,設(shè)計(jì)模式和設(shè)計(jì)原則應(yīng)該是較為熟悉的,或者說常用的設(shè)計(jì)模式和設(shè)計(jì)原則都是比較熟悉的。但是大部分書籍講到的是模塊內(nèi)部如何使用設(shè)計(jì)模式,并沒有重點(diǎn)強(qiáng)調(diào)邏輯架構(gòu)中模塊之間如何使用設(shè)計(jì)模式來讓邏輯架構(gòu)遵循軟件設(shè)計(jì)原則。
而我們設(shè)計(jì)或者推導(dǎo)邏輯架構(gòu)時(shí),主要就是用設(shè)計(jì)模式等方法來讓邏輯架構(gòu)中的各模塊之間的關(guān)系,以及模塊內(nèi)部的子模塊之間的關(guān)系符合軟件設(shè)計(jì)原則。
5.3關(guān)于模塊
如何用設(shè)計(jì)模式來讓模塊間的集成符合軟件設(shè)計(jì)原則,從而降低維護(hù)和擴(kuò)展的成本。架構(gòu)中的模塊之間,模塊和子模塊,子模塊和子模塊要遵守軟件設(shè)計(jì)的相關(guān)約束。如何遵守呢,領(lǐng)域建模和設(shè)計(jì)模式是兩個(gè)具體的方法。
即使不考慮模塊之間邊界和約束,光考慮模塊內(nèi)部的設(shè)計(jì),軟件設(shè)計(jì)原則和設(shè)計(jì)模式就已然是我們軟件工程師的必修課。再加上模塊之間的依賴或者邊界更加需要軟件設(shè)計(jì)原則和設(shè)計(jì)模式,那它們的地位就更加神圣不可替代。值得不斷的深入學(xué)習(xí),實(shí)踐,思考和總結(jié),這也是為設(shè)計(jì)邏輯架構(gòu)打基礎(chǔ),架構(gòu)師必修課。
雖然我們一開始總是從濫用開始,不過沒關(guān)系,一開始要做到不偏不倚總是很難的,慢慢的我們就可以窺見的其中的奧妙。
5.4具體技術(shù)在某些特定場景下的約束
這是具體的技術(shù)在某個(gè)特定場景下的約束:
總的來說,這里的這些約束更偏向于物理架構(gòu)上的約束,這里還是提前描述一下。同時(shí)每個(gè)物理架構(gòu)要解決的問題不一樣,導(dǎo)致它們要遵守的計(jì)算機(jī)科學(xué)與技術(shù)上的約束是不一樣的,這是架構(gòu)師們要整理,并倡導(dǎo)執(zhí)行的。
5.5邏輯架構(gòu)中的業(yè)務(wù)屬性約束
前面講到的是軟件研發(fā)領(lǐng)域的基本約束,這些基本約束在高粒度模塊中一般很少被提及,高粒度模塊之間的約束關(guān)系是根據(jù)業(yè)務(wù)中的思維概念提煉而來,比如電商中提煉出訂單,營銷活動(dòng),商品等等核心概念和核心域,對(duì)這些核心概念進(jìn)行定義,以確定它們之間的關(guān)系和邊界,從而形成技術(shù)上的統(tǒng)一業(yè)務(wù)約束。
同理,任何一個(gè)領(lǐng)域應(yīng)該都存在這樣的約束,只是這樣的約束并不是一層不變的,尤其是在業(yè)務(wù)系統(tǒng)中,業(yè)務(wù)理解發(fā)生了變化,這樣的約束也會(huì)隨之變化,而且業(yè)務(wù)中約束的目的是驅(qū)動(dòng)業(yè)務(wù)更好的前進(jìn)的重要保障。
我們拿國家這個(gè)架構(gòu)來做簡單的解讀,讀了十年歷史,大概總結(jié)出的一個(gè)國家級(jí)別主要架構(gòu)約束是這樣的:
歷史上不同時(shí)期的國家治理有不同的架構(gòu)(三省是頂層模塊,六部是二級(jí)模塊,然后依次做模塊分解,直到一村,一戶,這戶可以看最是領(lǐng)域模型)和規(guī)約。西周和東周的春秋時(shí)期靠的是周公旦制作的禮和樂作為國家架構(gòu)的約束,到了戰(zhàn)國時(shí)期,禮崩樂壞,百家爭鳴,最終以統(tǒng)一國家為目標(biāo)的法(這個(gè)法和保障民生的法是兩回事)成為秦國的架構(gòu)約束,得以讓他成功統(tǒng)一六國,但是很快這種法的約束又帶來了副作用,于是漢朝建立,確定孔子的儒家倫理道德作為國家架構(gòu)的主要約束。
然而這種以倫理和道德為主的架構(gòu)約束對(duì)王朝的前100年-150年是非常有效的,但是隨著時(shí)間的發(fā)展,這樣的約束會(huì)越來越弱,約束變?nèi)鮿t利益集團(tuán)會(huì)不斷的讓架構(gòu)中的模塊邊界變的模糊,有些模塊的利益變的更大,有些模塊的利益更小了,而且依賴關(guān)系變的混亂,從而使整體架構(gòu)的利益受到影響,同時(shí)由于利益牽絆太深很少有一個(gè)總架構(gòu)師有能力扭轉(zhuǎn)乾坤。最終于就會(huì)被另外一個(gè)王朝所洗牌,新的王朝會(huì)重新建立架構(gòu),重新設(shè)定模塊間的邊界和依賴,同時(shí)還是以道德和倫理作為主要的約束。這種局面從漢朝開始周而復(fù)始了2000年。
不管怎么說,一個(gè)符合時(shí)宜的架構(gòu)約束是有利于架構(gòu)向前發(fā)展的,而不符合時(shí)宜的約束反而是制約者架構(gòu)發(fā)展的。各種內(nèi)耗等情況應(yīng)運(yùn)而生,最終阻礙了業(yè)務(wù)向前拓展。
5.6約束小結(jié)
縱上所述,模塊間約束無處不在,技術(shù)上的約束是最最容易看懂的。越是細(xì)粒度模塊的約束,我們越容易學(xué)習(xí)和理解,比如軟件設(shè)計(jì)的原則等等,越是高粒度的模塊的約束,越抽象。需要對(duì)業(yè)務(wù)有深刻理解,對(duì)組織有深刻的理解,甚至對(duì)社會(huì)有深刻的理解。
六邏輯架構(gòu)復(fù)用
6.1復(fù)用
件復(fù)用包含很多內(nèi)容,比如說設(shè)計(jì)的復(fù)用,文檔的復(fù)用,代碼的復(fù)用等等。在本章節(jié)中的復(fù)用特指代碼的復(fù)用。
復(fù)用的收益
提煉的目的是實(shí)現(xiàn)復(fù)用,復(fù)用的目標(biāo)收益是:
復(fù)用的分類
對(duì)于復(fù)用,我從業(yè)務(wù)功能和非業(yè)務(wù)功能的角度來分了一下類,如下:
1)一種是跟業(yè)務(wù)無關(guān)的一些可復(fù)用的內(nèi)容,這些內(nèi)容存在于基礎(chǔ)架構(gòu)的每一個(gè)層次,但是還不能歸屬于邏輯架構(gòu),而且業(yè)務(wù)技術(shù)無關(guān)的復(fù)用不是本文討論的重點(diǎn),所以本文不會(huì)重點(diǎn)闡述MVC的設(shè)計(jì)思想是如何在不同的Web應(yīng)用中得以復(fù)用的。
2)還有一種是跟業(yè)務(wù)相關(guān)的可復(fù)用內(nèi)容,它的產(chǎn)生取決于抽象能力和技術(shù)功底,比如:
業(yè)務(wù)模塊復(fù)用的形式(物理架構(gòu)中要考慮的內(nèi)容)
具體的復(fù)用形式本質(zhì)上來說是物理架構(gòu)中要考慮的內(nèi)容,這里捎帶提一下。
1)二方庫形式
提煉成二方庫,誰使用誰依賴這個(gè)二方庫,這種情況又分成了兩個(gè)子類:
2)服務(wù)化形式
下沉成服務(wù),通過接口對(duì)外暴露,技術(shù)手段多種多樣,比如說HSF,SOFA對(duì)外暴露,或者HTTP對(duì)外暴露等,但是這里的重點(diǎn)不是在使用什么樣的技術(shù)手段,而是暴露的服務(wù)中應(yīng)該包含哪些內(nèi)容(有多少客戶,他們的需求的共性是什么,我們的業(yè)務(wù)本質(zhì)是什么,根據(jù)這些內(nèi)容來設(shè)計(jì)我們需要暴露的服務(wù),然后在考慮我們接口的規(guī)范。至于使用什么樣的服務(wù)容器之類的內(nèi)容基礎(chǔ)設(shè)施架構(gòu)同學(xué)會(huì)重點(diǎn)來考量,我們需要需要學(xué)習(xí)和理解,但是我們的重點(diǎn)還是在前兩個(gè),即服務(wù)到底是什么,以及服務(wù)接口的規(guī)范是什么,在這兩個(gè)上苦下功夫,對(duì)業(yè)務(wù)線的同學(xué)拿結(jié)果以及個(gè)人成長都有莫大的幫助)
3)展示組件
還有我們前端的各種可復(fù)用的展示組件的設(shè)計(jì),比如說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)用時(shí)有一些遠(yuǎn)程開銷,但是得益于RPC簡潔的二進(jìn)制協(xié)議(CPUTime的下降)和日益變小的RTT(RT的下降)及日益增加的帶寬,其遠(yuǎn)程開銷的代價(jià)漸漸變得不那么顯眼,甚至可以忽視。
那么是不是后者是不是可以代替前者呢?也并不是這樣,有的場景下前者是不能用后者來代替的,比如說通過業(yè)務(wù)流程的提煉抽象而得來的業(yè)務(wù)二方庫,這個(gè)是無法通過服務(wù)化來代替的,反而這種情況下,往往是服務(wù)化+二方庫同時(shí)出現(xiàn),起到一個(gè)很好的復(fù)用的作用。
所以在業(yè)務(wù)線的應(yīng)用邏輯架構(gòu)中,復(fù)用的重點(diǎn)即在提煉出共同的特性(模型上,流程上,計(jì)算模型上等),然后以二方庫或者服務(wù)化應(yīng)用的方式來進(jìn)行落地。那么如何在邏輯架構(gòu)中提煉出共同特性呢?
6.2抽象和提煉
抽象和提煉基本上會(huì)從下面幾個(gè)點(diǎn)出發(fā):
我相信很多人都有過這樣的經(jīng)驗(yàn)。由此可見提煉就是陰陽調(diào)和:
而這些都需要工程師們對(duì)領(lǐng)域建模和設(shè)計(jì)模式的抽象技術(shù),以及對(duì)相對(duì)的技術(shù)特性等計(jì)算機(jī)技術(shù)的深入掌握。這里需要強(qiáng)調(diào)光知道領(lǐng)域建模和設(shè)計(jì)模式等是不夠的,不同的技術(shù)選型特性不一樣,會(huì)導(dǎo)致在抽象的實(shí)現(xiàn)時(shí)產(chǎn)生不同的差別。
在復(fù)用這件事情上,抽象技術(shù)和計(jì)算機(jī)技術(shù)兩手抓,兩手都要硬。如果用中國古代傳統(tǒng)思想來比喻,那可能可以用陰來比喻抽象技術(shù),陽來比喻計(jì)算機(jī)技術(shù)。
尤其是陰,總是給人捉摸不定的感覺,但是如何深入學(xué)習(xí),堅(jiān)持實(shí)踐總結(jié),我們就會(huì)發(fā)現(xiàn)陰原來也是有具體方法論的,但是這個(gè)具體方法又不是看看書就能學(xué)會(huì)的,它對(duì)知行合一的要求更高。
從學(xué)習(xí)的步驟來說,一般的過程都是先從陽(計(jì)算機(jī)科學(xué)與技術(shù))開始,因?yàn)橄葟年帲ǔ橄蠛图軜?gòu)技術(shù))開始沒有陽作為支撐是很難把陰融會(huì)貫通的。而且最終要達(dá)到的是陰陽調(diào)和。如果我們過于偏重陰或者過于偏重陽,都會(huì)導(dǎo)致陰陽失調(diào),大概就是這個(gè)意思。
來到數(shù)據(jù)部門之后,我發(fā)現(xiàn)已經(jīng)不能用陰陽來形容我們要學(xué)的領(lǐng)域了,現(xiàn)在我們搞的比較多的是統(tǒng)計(jì)分析和機(jī)器學(xué)習(xí)(統(tǒng)計(jì)分析和機(jī)器學(xué)習(xí)有交集,也有區(qū)別),所以目前對(duì)我們團(tuán)隊(duì)來說,我們的同學(xué)有三門學(xué)科是必須要掌握的:
我最近一年看的比較多的是統(tǒng)計(jì)分析,有同學(xué)釘釘我問道:怎么連你也放棄領(lǐng)域建模了。我沒放棄,領(lǐng)域建模是抽象和架構(gòu)的重要方法(但不是唯一的方法,演繹和歸納也是,自頂向下分解也是),工程技術(shù)同學(xué)是不能放棄的。學(xué)習(xí)統(tǒng)計(jì)分析及統(tǒng)計(jì)學(xué)習(xí)是因?yàn)榻y(tǒng)計(jì)學(xué)習(xí)+計(jì)算機(jī)科學(xué)與技術(shù)可以更好的解決工程領(lǐng)域遇到的問題,這也是各條線的工程師需要掌握的技能。
6.3復(fù)用小結(jié)
復(fù)用是軟件中一個(gè)非常重要的學(xué)問,里面結(jié)合了抽象技術(shù)和計(jì)算機(jī)技術(shù),而抽象技術(shù)還依賴于對(duì)業(yè)務(wù)的理解程度,所以此非一日之功,需要長時(shí)間的鍛煉才能有所小成。
當(dāng)然,有時(shí)候即使在技術(shù)上可以抽象提煉,但是由于組織架構(gòu)的問題也會(huì)讓這樣的提煉無法落地,或者這里并不是一個(gè)穩(wěn)定的結(jié)構(gòu)從而導(dǎo)致經(jīng)常調(diào)整,帶來的結(jié)果是提煉的投入產(chǎn)出比比較小,從而導(dǎo)致無法提煉,這些這里就不詳細(xì)寫了。
七邏輯架構(gòu)分層
7.1分層的分類
工程骨架分層
分層幾乎是從每個(gè)工程師入門的時(shí)候都會(huì)接觸到的一個(gè)普世的概念,在一些書籍里,分層有的被稱之為tier,有的被稱之為layer,比如說OSI分層模型是用的Layer這個(gè)詞。而在一些文章里講到架構(gòu)時(shí)用的是tier這個(gè)詞,當(dāng)你去查看wiki的時(shí)候,那就更暈了,因?yàn)閣iki離tier和layer是混在一起講的。
談到分層,各種教科書中分層無不拿出景點(diǎn)的3個(gè)層次來闡述分層問題,如下:
然后還有擴(kuò)展出servicelayer,這些在工程骨架中非常常見,我們幾乎從來沒有見過不分層的工程骨架,所以當(dāng)我們討論架構(gòu)分層的時(shí)候,很多人腦海里第一映像就是工程骨架中的分層。
工程骨架的分層的一個(gè)重要目的是:成為代碼組織結(jié)構(gòu)的約束,防止代碼混亂不堪。
邏輯架構(gòu)分層
但是我們講的邏輯架構(gòu)分層不是指工程骨架分層,為什么不是?首先來看一下邏輯架構(gòu)的特點(diǎn):
根據(jù)這個(gè)特點(diǎn),我們可以模糊的看出邏輯架構(gòu)的分層主要是邏輯架構(gòu)中各模塊的調(diào)用關(guān)系,甚至更偏向從模塊職責(zé)的角度來進(jìn)行歸納從而得出層次。
這種分層的目的是:對(duì)同一類職責(zé)的模塊進(jìn)行職責(zé)上的約束,此時(shí)還不一定有代碼的存在。
兩者的區(qū)別
這么看來這兩個(gè)分層是有著本質(zhì)的區(qū)別:
也許有的同學(xué)會(huì)說了,再大的架構(gòu)(就比如說某個(gè)BU的邏輯架構(gòu)),我也可以將最靠近用戶的模塊劃分成presentationlayer,中間的所有模塊都劃分為businesslayer,最下面的我都劃分成presentationlayer。沒錯(cuò),你可以這樣做,但是這樣做基本沒有任何意義,不能帶來指導(dǎo)作用,失去的分層的目的。
7.2分層的案例
在文件系統(tǒng)或者網(wǎng)絡(luò)協(xié)議上,也有各種層次的封裝。如下圖所示:
這個(gè)圖中每個(gè)模塊在不同階段都有不同階段要解決的問題,然后每個(gè)模塊都可以分解,產(chǎn)生更細(xì)粒度的模塊,這里重點(diǎn)是讓大家了解到什么是邏輯架構(gòu)中模塊的分層。
不過這些都不是問題,問題是什么呢?
問題是我們必須時(shí)刻知道,目前我們在不同層次的這些模塊存在哪些問題,以及不同層次在解決什么問題。比如說上述的操作系統(tǒng)中文件系統(tǒng)和協(xié)議分層中,最底層的是跟硬件打交道,能夠精準(zhǔn)的控制硬件,中間是對(duì)操作系統(tǒng)的用戶暴露的,更簡單易用,上層是針對(duì)應(yīng)用來使用,解決特定領(lǐng)域的問題,不同的層次做了不同的抽象,也是在解決不同的問題。
7.3某些領(lǐng)域建模書籍之中的分層
很多人及一些書中,談分層必談工程骨架的分層,這個(gè)分層和架構(gòu)中的分層是兩回事,如果我們在談架構(gòu),那么我們要避免把重心放到項(xiàng)目骨架的分層上。
比如說領(lǐng)域建模的相關(guān)書籍中,經(jīng)常會(huì)講到service,domain,repository之流,這個(gè)些概念處于架構(gòu)中的什么位置,我們應(yīng)該什么時(shí)候去關(guān)心這些概念?
如圖所示,在細(xì)粒度模塊內(nèi)部,按照純技術(shù)職責(zé)來進(jìn)行劃分時(shí),我們將之?dāng)]成service,model,repository,integration之流的工程骨架,值得注意的是工程骨架的劃分層次和具體的業(yè)務(wù)邏輯架構(gòu)是沒有關(guān)系的,他更偏技術(shù),他的職責(zé)是對(duì)代碼做一個(gè)高層次的組織和管理。
按照正常流程,系統(tǒng)模型產(chǎn)出之后,應(yīng)該緊接著考慮模塊的設(shè)定,依賴,規(guī)約,但是很不幸,很多書籍和資料都把service,model,repository,integration這部分分層的內(nèi)容作為了領(lǐng)域的建模的最重要的重點(diǎn)之一。
某些書里的這種觀點(diǎn)是不符合實(shí)際工作流程的,實(shí)際工作時(shí),在領(lǐng)域模型之后我們先考慮的是架構(gòu)中的各個(gè)模塊的位置和職責(zé),以及模塊內(nèi)部的子模塊,模塊之間的關(guān)系,以及整體的約束等等(請(qǐng)參考文章開頭對(duì)架構(gòu)的定義)。具體表現(xiàn)就是我們在邏輯架構(gòu)圖中不會(huì)去畫什么service,model,repository,integration之類的層。
工程骨架的分層在細(xì)粒度模塊內(nèi)部,這是基礎(chǔ)設(shè)施架構(gòu)的一部分,也許是你手頭目前最重要的部分,但是對(duì)于整個(gè)應(yīng)用邏輯架構(gòu)來說不是最核心的部分也不是最需要先考慮的內(nèi)容。也就是說,即使你不分service,model之類的,對(duì)應(yīng)用邏輯架構(gòu)中模塊的職責(zé)劃分也是沒有影響的。
同時(shí)我也見過一些項(xiàng)目,應(yīng)用邏輯架構(gòu)比較明確了,但是在落地到物理架構(gòu)時(shí),把邏輯架構(gòu)中的所有模塊都放在service包里,而且沒有再分包,這就不合適了,邏輯架構(gòu)中的模塊完全沒有落地。
所以我現(xiàn)在在我們部門的項(xiàng)目中,堅(jiān)決避免將service,model,repository,integration之類的放到最高層來考慮。而是將邏輯架構(gòu)的設(shè)計(jì)切切實(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é)確定之后,模塊之間的依賴也必須要確定,然后模塊對(duì)外暴露接口需要定義規(guī)范和技術(shù)實(shí)現(xiàn)的手段。比如,如果是restful接口,那么應(yīng)該是什么樣的規(guī)范對(duì)外定義,如果是內(nèi)部的服務(wù)的接口,應(yīng)該是什么樣的規(guī)范。由于本文篇幅所限,此處不進(jìn)行詳述,前者可參考各大平臺(tái)的開放接口,后者可參考各BU內(nèi)部服務(wù)調(diào)用的相關(guān)規(guī)范,如果沒有,那說需要制定一個(gè)統(tǒng)一的規(guī)范。
八邏輯架構(gòu)是分粒度的
8.1邏輯架構(gòu)顆粒度樹
這里我引入了一個(gè)新概念:邏輯架構(gòu)顆粒度樹。
剛剛講的都是2維上的架構(gòu),我們可以看到,架構(gòu)推導(dǎo)是有方法的,而且如果對(duì)方法進(jìn)行提煉,就是橫和豎的問題,但是正如我們開始講到的,架構(gòu)也可以是3維的,那就是在二維的模塊中存在各種粒度子模塊或者父模塊。
如果非要打個(gè)比喻的話,那么下面的宇宙星神合體是一個(gè)大的架構(gòu):
里面分成了很多小模塊,比如物質(zhì)飛船,探測器等等,而每個(gè)小模塊又是有很多基礎(chǔ)模塊構(gòu)成,宇宙星神合體中只有3個(gè)層次,及基礎(chǔ)部件,模塊,及最終的星神合體,它們代表著不同的粒度。而對(duì)于業(yè)務(wù)復(fù)雜的架構(gòu)來說,粒度會(huì)更多,層次就會(huì)更多。這取決于N個(gè)研發(fā)資源投入在某個(gè)模塊上的效率最高,而這個(gè)N在某個(gè)階段的技術(shù)限制下應(yīng)該是一個(gè)比較穩(wěn)定的值!
抽象一下,模塊在不同粒度上,可以整成這么一棵樹:
邏輯架構(gòu)粒度樹的3條原則:
上述的樹形結(jié)構(gòu),只能描繪出模塊和父模塊,子模塊的關(guān)系,但是不能完整的描繪出模塊之間的關(guān)系,是處于同一層次,還是處在不同層次(就是前面提到的應(yīng)用邏輯架構(gòu)中橫的問題和豎的問題)。
那么用什么樣的圖形既可以生動(dòng)的表達(dá)出模塊和父模塊,及子模塊的關(guān)系,又能表達(dá)出不同模塊之間的關(guān)系呢,我想了很久,也沒有想到一個(gè)更容易理解的圖形,最后產(chǎn)出了下面這么一幅圖:
圖中有三層,但是現(xiàn)實(shí)生活中可能超過三層,也可能低于三層。我們能歸納的層次越高,那可能我們接觸的東西就越寬廣,越精深。
這里有一個(gè)嚴(yán)肅的話題需要提一下:是不是一線工程師不用考慮邏輯架構(gòu)問題?當(dāng)然不是,任何一個(gè)同學(xué),你手頭的工作都是跟架構(gòu)相關(guān)的,你負(fù)責(zé)模塊可能也存在子模塊,而且必定會(huì)存在父模塊,出于工作,你必須要理解不斷迭代你模塊中的設(shè)計(jì),同時(shí)隨著能力的成長,你必須要關(guān)注你的父模塊,父模塊的父模塊,日積月累,你可以hold住的模塊粒度會(huì)越來越大,你的職責(zé)和能力要求會(huì)越來越大。
8.2模塊顆粒度樹落地情況
在下述架構(gòu)模塊顆粒度樹中,并沒有模塊和模塊之間的依賴關(guān)系,這里只是為了概要的說明模塊落地到物理架構(gòu)中的一個(gè)演變過程,而具體的案例我們放在后面的文章中來進(jìn)行闡述。
模塊樹上的這些不同粒度的模塊,在具體落地成物理架構(gòu)時(shí),可以是不同的形式,如下:
為什么會(huì)出現(xiàn)這種情況呢,因?yàn)椴煌哪K在業(yè)務(wù)的發(fā)展的不同時(shí)期:
那么我們來看看一個(gè)網(wǎng)站從小到大的邏輯架構(gòu)模塊樹落地的變化情況。
小型業(yè)務(wù)邏輯架構(gòu)的模塊樹落地情況
很顯然,這里是一個(gè)電商網(wǎng)站起步時(shí)候的樣子,所有模塊都有模有樣,只是模塊中的邏輯比較簡單,這些模塊都以包的形式存在于一個(gè)應(yīng)用之中,這個(gè)應(yīng)用是一個(gè)大泥球。但是由于模塊的職責(zé)劃分合理,粒度的治理也比較符合發(fā)展要求,所以這樣的應(yīng)用在分拆成分布式的時(shí)候阻力會(huì)比較小。而那些模塊職責(zé)不合理的大泥球應(yīng)用,隨著業(yè)務(wù)的發(fā)展,要分拆成分布式應(yīng)用,阻力就大很多。
中型業(yè)務(wù)邏輯架構(gòu)的模塊樹落地情況
這是一個(gè)度過初期階段的電商網(wǎng)站,營銷,商品,交易模塊等已經(jīng)成型,而且得益之前的模塊劃分,架構(gòu)師可以很快的將初期的多個(gè)頂級(jí)包,分拆出來,變成多個(gè)應(yīng)用。
大型業(yè)務(wù)邏輯架構(gòu)的模塊樹落地情況
到了這個(gè)時(shí)期,已經(jīng)是一個(gè)大型電商網(wǎng)站的樣子了,營銷平臺(tái)內(nèi)部已經(jīng)分拆出了多個(gè)應(yīng)用,得益于上一階段中各模塊職責(zé)的合理分配,所以架構(gòu)師將在將物理架構(gòu)進(jìn)化成這個(gè)樣子的時(shí)候,力氣不需要花在邏輯架構(gòu)的治理上,可以把精力集中投入到物理架構(gòu)及基礎(chǔ)設(shè)施架構(gòu)的建設(shè)上,比如同城容災(zāi),異地多活等等。
8.3再發(fā)展成巨型的架構(gòu)呢?
中臺(tái)概念抽象
我不知道,比如中臺(tái)是不是,要把電商業(yè)務(wù)中所有的相對(duì)穩(wěn)定的核心抽象出來,可能是領(lǐng)域模型,可能是業(yè)務(wù)流程轉(zhuǎn)換而成的系統(tǒng)流程,可能是一個(gè)計(jì)算模型或者算法等等。然后變化的內(nèi)容(前臺(tái))可以依托于這個(gè)大的核心概念快速的迭代。如果需要圖形化來做概要的理解,我想應(yīng)該是這樣的:
一旦要做一個(gè)中臺(tái),那么以為著這個(gè)中臺(tái)對(duì)前臺(tái)來說就是一個(gè)技術(shù)產(chǎn)品,則要考慮如下幾個(gè)方面的內(nèi)容:
目的就是要提高客戶的生產(chǎn)效率。
是否存在中臺(tái)的判斷依據(jù)是什么?
多個(gè)業(yè)務(wù)線有無重復(fù)的流程抽象,有無重復(fù)的領(lǐng)域模型抽象,有無重復(fù)的計(jì)算模型(數(shù)據(jù)結(jié)構(gòu)和算法)等等,有無重復(fù)的輔助性設(shè)施。他們是否在重復(fù)建設(shè),等等。
在演變的過程中變化是什么呢?需要的是學(xué)習(xí)能力,溝通能力,協(xié)調(diào)資源的能力,領(lǐng)導(dǎo)力,影響力,評(píng)估人的能力和用人的能力等等。這些能力需要涉及的范圍都從一個(gè)小的組織向一個(gè)更大的組織前進(jìn)。
大音希聲,大象無形,不管如何發(fā)展,基礎(chǔ)的規(guī)律都還是不變的。
8.4邏輯模塊落地的相關(guān)考量維度
當(dāng)一個(gè)邏輯模塊要落地時(shí),我們?nèi)绾闻袛嘁粋€(gè)模塊落地成包,還是應(yīng)用等等,有很多判斷的維度,比如:
效率(多少人維護(hù)一個(gè)應(yīng)用效率最高)
到底多少人的團(tuán)隊(duì)協(xié)作效率最高?作為一個(gè)應(yīng)用,在技術(shù)不斷進(jìn)步的情況下(比如說新的容器之類的),或者要面對(duì)的業(yè)務(wù)的復(fù)雜度不同的情況下,同時(shí)可維護(hù)的人數(shù)也是不一樣的,具體目前變化到多少,目前基本是靠經(jīng)驗(yàn),然后遇到問題再調(diào)整,根據(jù)主管的經(jīng)驗(yàn)不斷調(diào)整和優(yōu)化,以達(dá)到一個(gè)適合當(dāng)前階段的最優(yōu)值,目前我自己這邊大概5人左右一個(gè)攻堅(jiān)小組,遇到更大問題域,那就拆解。
穩(wěn)定性
性能
這里面,效率,穩(wěn)定性,性能是最影響邏輯架構(gòu)落地成物理架構(gòu)的三大主要因素。
九全文總結(jié)
9.1架構(gòu)的定義和價(jià)值
我們在文章的開頭對(duì)架構(gòu)兩個(gè)字給出了一個(gè)官方定義,然后按照筆者自己對(duì)架構(gòu)的理解又對(duì)架構(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)都是在解釋不同的問題,比如:
正確分析出當(dāng)前的場合(受眾和目的)應(yīng)該用什么樣的架構(gòu)來闡述我們的意圖是非常重要的。
同時(shí)我們可以看到小到一個(gè)mis系統(tǒng),大到整個(gè)阿里,都可以用架構(gòu)的角度來解釋,架構(gòu)中出現(xiàn)的各種中臺(tái),后臺(tái),各種框架等等其實(shí)都是架構(gòu)方法產(chǎn)出的結(jié)果。系統(tǒng)大小不一樣,抽象的方法是類似的。
架構(gòu)產(chǎn)生之后,隨著業(yè)務(wù)的迭代,架構(gòu)不治理,模塊職責(zé)和依賴,層次不清晰,約束不明確。穩(wěn)定性,性能,成本都受到影響。積弊越久,回頭越難,有時(shí)候不得不重頭來過。
9.2自底向上重度依賴于演繹和歸納
為了避免推倒重造的問題發(fā)生,我們需要不斷的自底向上的方式來修正架構(gòu),修正其實(shí)是在做局部的模塊重構(gòu),談到修正,具體的方法是由這里就不得正視歸納和演繹的重要性了,而這里的演繹和歸納是抽象的核心概括。
自底向上的推導(dǎo)的重點(diǎn)在于演繹和歸納,越是底層的越是要使用演繹的方法,越是高層的越是使用歸納。
這兩種方法應(yīng)該什么時(shí)候使用?顯然當(dāng)我們的目標(biāo)(比如說業(yè)務(wù)目標(biāo))或者結(jié)論是非常高粒度的時(shí)候,需要分解,那么使用自頂向下的推導(dǎo),在規(guī)劃未來時(shí)一般會(huì)用到類似的自頂向下的方法,產(chǎn)出我們宏觀結(jié)論。
而如果是產(chǎn)品方案已經(jīng)明確,程序員需要理解這個(gè)業(yè)務(wù)需求,并根據(jù)產(chǎn)品方案推導(dǎo)出架構(gòu),此時(shí)一般使用自底向上的方法,而領(lǐng)域建模就是這種自底向上的分析方法。
對(duì)于自底向上的分析方法,如果提煉一下關(guān)鍵詞,會(huì)得到如下兩個(gè)關(guān)鍵詞:
演繹
演繹就是邏輯推導(dǎo),越是底層的,越需要演繹:
歸納
這里的歸納是根據(jù)事物的某個(gè)維度來進(jìn)行歸類,越是高層的,越需要?dú)w納:
關(guān)于歸納,我們前面已經(jīng)做了大量的講解,所以這里我們重點(diǎn)闡述一下演繹:
1)我們從對(duì)業(yè)務(wù)的理解,演繹出用例,從用例演繹抽象出業(yè)務(wù)概念模型,從業(yè)務(wù)概念演繹抽象出系統(tǒng)模型,從系統(tǒng)模型演繹抽象出物理存儲(chǔ)模型。這是一個(gè)從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)我們從對(duì)業(yè)務(wù)的理解,演繹出用例,從用例演繹出業(yè)務(wù)流程,再從業(yè)務(wù)流程演繹抽象成系統(tǒng)流程,然后再演繹成數(shù)據(jù)流。這是也是一個(gè)從A推導(dǎo)出B,從B推導(dǎo)出C',從C'推導(dǎo)成D',從D'推導(dǎo)出E'的過程。這個(gè)推導(dǎo)過程比如有方法論輔助,否則邏輯的深度和廣度都會(huì)受到影響。
總的來說:演繹推導(dǎo)的層次越深,分支邏輯越多,越能穿透迷霧,看問題就越透徹,說明功力越深厚。
打個(gè)比喻就是:對(duì)應(yīng)相同品種的樹來說,小樹的根系和大樹的根系在地下深入的長度和廣度是完全不一樣的,人的邏輯能力大抵也是如此。
其實(shí)我們工作中很多時(shí)候都在使用演繹和歸納,只是我們不知道我們在使用這類方法,看到這篇文章之后也許可以給大家?guī)ヒ恍┧伎?,看清楚我們自己以前的工作到底是如何使用演繹和歸納的,以及如何改進(jìn)以前的方法。
9.3邏輯架構(gòu)的自底向上推演
除了自底向上的通用思考方法之外,我們還必須要了解計(jì)算機(jī)領(lǐng)域的相關(guān)技能和套路才能產(chǎn)出合適的結(jié)果:
這張圖是有嚴(yán)密的邏輯路徑的,每個(gè)步驟的輸入,都是上個(gè)步驟的輸出。更關(guān)鍵的是這個(gè)張圖是有順序的,做架構(gòu)要從上往下做,不可自顧自,不可撇開業(yè)務(wù)閉門造車。
為什么前面我們問題空間領(lǐng)域模型聊了這么多,原因就是問題空間的領(lǐng)域建模其實(shí)是分析階段,如果分析階段我們沒有做正確,那么設(shè)計(jì)階段我們能做正確的可能性是非常小的。
分析階段,我們得出了正確的分析產(chǎn)出,那么我們在設(shè)計(jì)階段,又根據(jù)合理正確的方法論,我們就可以得到合理正確的應(yīng)用邏輯架構(gòu)。
同時(shí)我們可以看出領(lǐng)域建模是抽象和架構(gòu)的重要方法,但不是唯一的方法,因?yàn)闅w納和演繹也是抽象及架構(gòu)的重要方法,自頂向下推演也是架構(gòu)的重要方法。
這套方法論的關(guān)鍵性總結(jié)應(yīng)該是這樣的:
1)架構(gòu)問題是我們工作中常見的問題,我們要注意識(shí)別并定義架構(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)出是通過對(duì)前面的產(chǎn)出歸納和演繹出來的
6)應(yīng)用邏輯架構(gòu)推導(dǎo)所使用的歸納和演繹方法涉及到很多具體的知識(shí)
最重要的是這個(gè)過程是不斷迭代的,這句話比什么都重要,只有運(yùn)動(dòng)著的架構(gòu),沒有靜止的架構(gòu)。有的架構(gòu)運(yùn)動(dòng)時(shí)進(jìn)行不斷的重構(gòu)和調(diào)整,所以經(jīng)久不衰,有的架構(gòu)缺乏這樣的自我否定機(jī)制,最終走向衰敗。
PS:由于我架構(gòu)水平,寫作水平,及認(rèn)知所限,有很多我自己都不知道自己不知道的規(guī)律和事實(shí)存在。所以文中整體思路和細(xì)節(jié)之處不免存在紕漏之處,還望大家不吝指出,謝謝。
Copyright @ 2013-2020 中國福建網(wǎng) 版權(quán)所有
聯(lián)系我們
免責(zé)聲明:本站為非營利性網(wǎng)站,部分圖片或文章來源于互聯(lián)網(wǎng)如果無意中對(duì)您的權(quán)益構(gòu)成了侵犯,我們深表歉意,請(qǐng)您聯(lián)系,我們立即刪除。