撸一发springboot——项目架构分析（第一篇）

关于项目架构的一些小心得

1.模块分类原则

模块分为三类，一类是项目的基础模块，包括common和core;一类是功能模块，不涉及任何业务代码，只是单纯的功能实现；一类是业务模块，所有与业务不相干的方法和类不能出现在其中；
这三类模块依赖关系及其功能是这样的：common为通用模块，用于存放DTO和工具类和一些base接口

项目架构技巧：基于common 和core模块 manager层的简单解耦

我的项目是将功能模块和业务模块划分开的；功能模块和功能模块之间原则上应该是松耦合的，既功能模块之间是不相互依赖的，如何能做到呢？
答案是利用好common和core模块，通常的，我们可以将一些公共类放到common中，这样所有模块要使用公共类只要引用common即可；而一些特殊的情况比如 a功能模块需要使用b功能模块的类这种情况如何解决？在core中定义好接口 b的类继承这个接口，然后注入到spring，a从spring中拿这个bean，这样a就不必依赖b,达到解耦的目的。

举例：
现假设有一个redis模块，一个rabbitMQ模块，rabbitMQ模块需要使用redis模块的类；

记住，我们不直接从rabbitMQ中依赖redis(直接依赖的缺点显而易见，移植性很差)，我们在core中定义一个接口：

public interface TestRedis{
   }

在redis模块中实现这个接口并注入到spring：

@service
public class testRedisImpl implements TestRedis{
   
}

在rabbitMQ模块中拿这个类：

public class test{
   
   @Autowired
   TestRedis testRedis;
}

这样就比较简单的实现了模块间解耦；

manager层的使用

我的分层原则是service层只能给controller层使用，而manager层出现的目的就是供其他service层使用，就是说service不直接调用service，而是通过manager来做调用；这样做的好处是：

1.manager层相当于一个门面模式，方便代码的统一管理。
2.service层可以只专注于业务逻辑等或功能，以遵循单一职责的原则

我项目中部分功能模块并未完全遵守以上原则，是因为项目早期的架构的时候思路和经验的问题遗留下来的，希望大家注意。

我看过有的项目架构以三层模型来分模块，也就是分成了service模块，controller模块，dao模块等。我觉得这样分模块并未发挥ma