爲什麼要搭建多模塊的maven項目？

我們爲什麼要搭建多模塊的maven項目呢？

以多模塊的方式組織項目，其實也是maven一直倡導的。做開發的同學都知道的一個概念就是“低耦合，高內聚”，將項目劃分多模塊，可以極大的增大代碼的重用性，防止隨着項目的增大，pom文件越來越臃腫。

對於一般的java項目我們一般是這麼分層的：

• dao層負責數據庫的交互。
• service層主要處理業務邏輯。
• web層負責與客戶端交互。
• pojo層存放的是實體類。
• common層存放我們常用的一些公用的工具類等。

對應的，在一個項目中，我們會看到一些包名：

• com.leeyom.ssm.dao
• com.leeyom.ssm.service
• com.leeyom.ssm.web
• com.leeyom.ssm.common
• com.leeyom.ssm.pojo

這樣整個項目的框架就清晰了，但隨着項目的進行，你可能會遇到如下問題：

• 這個應用可能需要有一個前臺和一個後臺管理端，你發現大部分dao，一些service，和大部分util是在兩個應用中均可用。
• pom.xml中的依賴列表越來越長以重用的，但是，由於目前只有一個項目（WAR），你不得不新建一個項目依賴這個WAR，這變得非常的噁心，因爲在Maven中配置對WAR的依賴遠不如依賴JAR那樣簡單明瞭，而且你根本不需要com.leeyom.ssm.web。有人修改了dao，提交到svn並且不小心導致build失敗了，你在編寫service的代碼，發現編譯不過，只能等那人把dao修復了，你才能繼續進行，很多人都在修改，到後來你根本就不清楚哪個依賴是誰需要的，漸漸的，很多不必要的依賴被引入。甚至出現了一個依賴有多個版本存在。
• build整個項目的時間越來越長，儘管你只是一直在web層工作，但你不得不build整個項目。
• 某個模塊，比如util，你只想讓一些經驗豐富的人來維護，可是，現在這種情況，每個開發者都能修改，這導致關鍵模塊的代碼質量不能達到你的要求。

我們會發現，其實這裏實際上沒有遵守一個設計模式原則：“高內聚，低耦合”。雖然我們通過包名劃分了層次，並且你還會說，這些包的依賴都是單向的，沒有包的環依賴。這很好，但還不夠，因爲就構建層次來說，所有東西都被耦合在一起了。因此我們需要使用Maven劃分模塊。