印象中有些日子沒有寫文章了，最近一直在放飛自我，今天和大家分享的一些在搭建腳手架和編程中的一些實踐原則。所有目標都是“清晰架構(gòu)分層”。

使用統(tǒng)一的依賴管理

這種方式是基于我多年來的實踐。最開始我也將項目類庫及其版本隨意的管理，大部分情況下它們能夠正常的工作，遇到版本升級和依賴沖突就很頭疼。于是模仿一些知名開源的依賴的管理，定制自己的BOM，就像這樣:

<dependencyManagement> 
    <dependencies> 
        <dependency> 
            <groupId>cn.felord.</groupId> 
            <artifactId>my-bom</artifactId> 
            <version>1.0</version> 
            <type>pom</type> 
            <scope>import</scope> 
        </dependency> 
    </dependencies> 
</dependencyManagement>

這樣你的依賴管理將非常清晰， 在升級第三方依賴或者增減依賴的時候，只需要升級這個依賴的版本即可。

約定大于配置

眾所周知Spring Boot的一個重要的特點就是約定大于配置。但是我在一些開源腳手架和一些項目中看到的卻不是延續(xù)這一思想，用了大量的代碼實現(xiàn)了一些可有可無的自定義配置。比如我在某個項目的Spring Security依賴中看到，自定義了所有的默認配置，將簡單的問題復(fù)雜化卻收效甚微，默認提供的PasswordEncoder不好用嗎？能復(fù)用就復(fù)用，用最少的配置解決問題。

MVC分工應(yīng)該專注和簡潔

控制器

關(guān)于控制器，也就是Controller，它更多的角色應(yīng)該是一個協(xié)調(diào)者和委托者，而不承擔(dān)具體業(yè)務(wù)邏輯的執(zhí)行工作?？刂破鲬?yīng)該專注于HTTP層面的功能，比如參數(shù)的綁定處理，序列化和反序列化，具體的業(yè)務(wù)委托給下游的服務(wù)層。

還有一個點就是接口的命名風(fēng)格要一致，還要有層次感和語義化。比如/api/user/{id}、/api/order/{id}、/api/order/user/{id}。

服務(wù)層

服務(wù)層我遇到的問題就是出口分散問題，很多同學(xué)訂單的出口可能根據(jù)某些原因分散在其它的服務(wù)層接口，而不是集中于OrderService中。大多數(shù)情況下，我覺得集中管理有利于后續(xù)的迭代維護，保證了各個Domain業(yè)務(wù)之間的相對獨立性。

還有一點，同一個Spring容器下服務(wù)層之間的相互調(diào)用容易引起依賴循環(huán)問題，比如UseService要調(diào)用OrderService查詢訂單，而OrderService可能又依賴了UserService，最好的辦法是服務(wù)層之間盡量不相互調(diào)用，去調(diào)用持久層的OrderMapper，當然一些功能性的接口服務(wù)例外，例如短信服務(wù)、三方接口這一類。

說到短信服務(wù)、三方接口，這一類穩(wěn)定的業(yè)務(wù)功能建議作為類庫集成，既方便管理又可重用。

工具類

Spring內(nèi)部的工具類和apache common包的工具類已經(jīng)足夠應(yīng)付大部分情況，如果真的不滿足再考慮去寫工具類，工具類解決的一定是局部問題，不要把業(yè)務(wù)功能相關(guān)的東西封裝成工具類。