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

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

這種方式是基于我多年來(lái)的實(shí)踐。最開(kāi)始我也將項(xiàng)目類(lèi)庫(kù)及其版本隨意的管理，大部分情況下它們能夠正常的工作，遇到版本升級(jí)和依賴(lài)沖突就很頭疼。于是模仿一些知名開(kāi)源的依賴(lài)的管理，定制自己的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>

這樣你的依賴(lài)管理將非常清晰， 在升級(jí)第三方依賴(lài)或者增減依賴(lài)的時(shí)候，只需要升級(jí)這個(gè)依賴(lài)的版本即可。

約定大于配置

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

MVC分工應(yīng)該專(zhuān)注和簡(jiǎn)潔

控制器

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

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

服務(wù)層

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

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

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

工具類(lèi)

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