導航
- 前言
- 流水線
- 架構的藝術
- 專案架構
- 理解阿里應用分層架構
- superblog專案架構
- 結語
- 參考
本節是《Spring Boot 實戰紀實》的第7篇,感謝您的閱讀,預計閱讀時長3min。 智客工坊出品必屬精品。
前言
關於架構的理解,一千個人心中有一千個哈姆萊特。這和專案經驗和團隊文化有很大關係。
我想很多人其實對程式設計是有誤解的。在中國古代提倡六藝,後面又提倡琴棋書畫,這些都是才藝或者技藝。程式設計也是一門技藝,並沒有大家想象的那麼神祕。當我們通過書本學到一門程式語言的時候,往往只是學到了一些技巧,一些技術,但是要真正的成為行家,大拿,那就需要藝術了。在程式設計中,架構就是一門藝術。
流水線
1769年，英國人喬賽亞·韋奇伍德開辦埃特魯利亞陶瓷工廠，在場內實行精細的勞動分工，他把原來由一個人從頭到尾完成的製陶流程分成幾十道專門工序，分別由專人完成。這樣一來，原來意義上的“製陶工”就不復存在了，存在的只是挖泥工、運泥工、扮土工、製坯工等等製陶工匠變成了製陶工場的工人，他們必須按固定的工作節奏勞動，服從統一的勞動管理。
富士康的流水線工作機制,大家都不陌生。流水線實際上就是通過分工來提供生產效率。
現代的軟體專案,很少是一個人能夠開發的。往往是一個團隊協作完成。這個團隊就就會報包括專案經理,UI設計師,前端技術,後端技術,DBA等。這些不同工種的相互協作,最終互動一款完整的軟體。
有了分工,專人專事,多人協作,就必須有一套約定俗稱的專案開發流程,而這套流程其實規定了程式碼的組織,變數的命名等。這套流程中的程式碼組織繼續規範和沉澱就變成了專案架構規範。
架構的藝術
架構是一門藝術,和開發語言無關。架構是整個專案的頂層設計。特別是在Devops的流行的今天,開發人員也要參與專案部署和運維的工作。站在專案架構的角度,架構不僅要考慮專案的開發,還要考慮專案的部署。
本文更多地聚焦於專案開發的架構,即中小型專案的搭建。
架構的功能:
- 方便團隊分工
- 職責分離
- 可擴充套件
- 重用
- 方便排錯
理解阿里應用分層架構
在國內Java應用方面,阿里應該是權威。在阿里《Java開發規範》中有一個推薦的分層。
-
開放 API 層： 可直接封裝 Service 介面暴露成 RPC 介面； 通過 Web 封裝成 http 介面； 閘道器控制層等。
-
終端顯示層：各個端的模板渲染並執行顯示的層。當前主要是 velocity 渲染，JS 渲染，JSP 渲染，移
動端展示等。 -
Web 層：主要是對訪問控制進行轉發，各類基本引數校驗，或者不復用的業務簡單處理等。
-
Service 層：相對具體的業務邏輯服務層。
-
Manager 層：通用業務處理層，它有如下特徵：
1） 對第三方平臺封裝的層，預處理返回結果及轉化異常資訊，適配上層介面。
2） 對 Service 層通用能力的下沉，如快取方案、中介軟體通用處理。
3） 與 DAO 層互動，對多個 DAO 的組合複用。 -
DAO 層：資料訪問層，與底層 MySQL、Oracle、Hbase、OB 等進行資料互動。
-
第三方服務：包括其它部門 RPC 服務介面，基礎平臺，其它公司的 HTTP 介面，如淘寶開放平臺、支
付寶付款服務、高德地圖服務等。 -
外部資料介面：外部（應用）資料儲存服務提供的介面，多見於資料遷移場景中。
分層領域模型規約：
- DO（Data Object）：此物件與資料庫表結構一一對應，通過 DAO 層向上傳輸資料來源物件。
- DTO（Data Transfer Object）：資料傳輸物件，Service 或 Manager 向外傳輸的物件。
- BO（Business Object）：業務物件，可以由 Service 層輸出的封裝業務邏輯的物件。
- Query：資料查詢物件，各層接收上層的查詢請求。注意超過 2 個引數的查詢封裝，禁止使用 Map 類
來傳輸。 - VO（View Object）：顯示層物件，通常是 Web 向模板渲染引擎層傳輸的物件。
manager層的使用
其它層的關係,大家都很容易理解。但是manager層和service層容易搞混。這也是初學者容易迷惑的地方,筆者也是反覆揣摩和多次查閱了相關資料,有了一個比較合理的理解。
筆者認為,controller呼叫service層,service層呼叫dao層(或Mapper層)。manager層出現的目的就是供其他service層使用，就是說service不能直接呼叫service，而是通過manager來做呼叫。
- manager層是對service層的公共能力的提取。
- manager層還可以下沉內部的common/helper等。
筆者所在團隊,Java專案的搭建也是參照的這套標準。但是沒有放之四海而皆準的標準,在實際搭建中都會根據實際業務和團隊文化而因地制宜的有所改造。
這裡值得注意的是manager層,我想可能很多專案是沒有使用這個層的。或者直接使用的common/helper作為替代。
superblog專案架構
鑑於以上的闡述,在設計superblog的架構上就基本心中有數了。我們姑且將部落格中的創作稱為作品,這裡就以作品建立為例來展示一下專案各層之間的呼叫關係。
筆者把Superblog創作定義為以下型別:
- Article(文章)
- Weekly(週刊)
- Solution(解決方案)
以上這種分層和呼叫關係和開發語言沒有太多關係,無論是C#還是Java都是適用的,這就想三層框架，ｍｖｃ架構一樣,是一種設計理念和設計模式。
架構的關係明確之後,搭建框架就是水到渠成的事情。
講到這裡,終於要輪到Springboot上場了。下面我們就以Springboot來搭建一套開發架構。
本專案包含一個父工程super-blog和 blog-base, blog-pojo,blog-dao, blog-manager, blog-service,blog-web,blog-webapi。
- blog-base,blog-pojo 為其他模組的公共模組,blog-base依賴blog-pojo;
- 七個子模組都依賴父模組,blog-dao 依賴 blog-base;
- blog-service 依賴 blog-dao，也就間接依賴 blog-base;
- blog-web和blog-webapi是並列的。都依賴 blog-service,也就間接依賴blog-base和blog-dao。
- blog-manager是blog-service中公共的業務層。
模組的概念在不同語言之間叫法不同。在
.NET Core專案中,每一層都是一個程式集,程式集之間通過引用來表達呼叫關係。在Springboot專案中,每一層都是一個模組,各個模組之間通過maven配置依賴關係。
比如,以下配置就表示父工程下有哪些子模組。
<!--宣告子模組-->
<modules>
<module>blog-pojo</module>
<module>blog-dao</module>
<module>blog-service</module>
<module>blog-manager</module>
<module>blog-base</module>
<module>blog-webapp</module>
</modules>
而這個配置又表示了一種子模組之間的依賴關係。
<!-- 新增 blog-service 的依賴 -->
<dependency>
<groupId>com.zhike</groupId>
<artifactId>blog-service</artifactId>
<version>0.0.1-SNAPSHOT</version>
</dependency>
值得注意的是,在Springboot之間通常使用單向依賴,避免產生相互引用。雙向引用在編譯階段不會報錯,但是執行時就會異常。
按照慣例,也要將搭建好的專案架構展示一下:
結語
本文主要是從理論上對分層架構的進行了闡述。下一篇會講解搭建springboot多模組的詳細步驟。對於新手同學可以參考《零基礎上手JavaWeb》
和《使用IDEA快速搭建一個SpringBoot專案》（詳細）,先嚐試搭建一個最簡單的Springboot專案。
選擇並聚焦到一點，把事情做到極致。