一、业务场景
工作多年，在真实的项目开发中经常会遇到将一个项目拆分成多个工程的情况，比如将一个真实的项目拆分成controller层，service层，
dao层，common公共服务层等等。这样拆分比较有利于分清各自所属层需要做的事情，也非常便于管理个层次之间的代码，职责比较清晰。各
个层次之间也会相互依赖，比如controller层需要依赖common层，则直接引入；service层需要引入common层也直接引入；dao层也是同理。
这种处理方式也没什么问题，整个项目依然能够顺利的跑起来，可是有没有什么更加好的方式来处理这些依赖关系呢？
二、需求分析
新项目中是按照分层架构来设计、搭建的，使用cola4.0的设计理念进行分层，主要分为start-启动层，只有一个启动类；adapter-适配层，
类似于controller层；app层，类似于service层；domain层表示领域层，提供领域服务，使用DDD的设计理念；Infrastructure基础设施服务层，提供
数据库操作服务。项目在原有的这些基础之上，新加了一层common，抽取一些公共的服务类，如返回数据的枚举值，统一异常处理，自定义异常等
等。这样算下来层次就比较多。总共有6层，除了start层之外，其他层都需要依赖common层在项目内部提供的服务。如果按照以前的处理方式，
每一层都单独引入common层，pom文件里面需要加的内容也比较多。那如何解决这个问题呢，一种可行的方案就是使用maven的依赖传递。
三、解决方案
假如项目中有依赖关系A-->B-->C-->D，A依赖B，B依赖C，依此类推，则A就可以间接的依赖项目D，这就是Maven中的依赖传递。根据这一特性
对上面的项目进行依赖层次的改进为:start-->adapter-->app-->infrastructrue-->domain-->common。从之前的每个工程中都需要引入common层，改为
现在只需要domain层去依赖common层，并且其他项目也能够正常使用。这种单项依赖让工程之间的关系变得更加的清晰，说得直白通俗一点就是上层
只依赖下层。这种处理方式也大大地简化了pom文件中的内容，只需要在某个工程里面引入其需要依赖的下层项目的坐标即可。经过测试，这种处理方式
完全可行，现在项目中也已经真正的使用起来，在今后的项目开发中，自己也一定会继续采用这种方式来处理项目之间的依赖关系。如果各位小伙伴有更好
的建议，欢迎留言。
参考文章:
https://blog.csdn.net/significantfrank/article/details/110934799
https://www.cnblogs.com/cy0628/p/15034450.html