问题背景：在尝试做毕业设计的时候，打算项目结构式单体多模块的方式。但是这是我第一次使用多模块开发，所以产生了一些疑问。
问题一：一般在项目中，公共的代码会放在一个模块中（假设模块common），那么一些不算是公用的代码怎么放呢？比如说：一些依赖的一些配置，怎么存放呢？也放在这个common吗？假设我想用minio，minio需要引入依赖，还需要创建bean，然后是工具类，那么工具类肯定是放在common里的，那这个创建bean的配置类放在哪里呢？也放在common中吗？又比如说：我想使用sa-token框架实现鉴权。我们需要也引入依赖，然后配置注册拦截器。那么这个配置也放在common吗？这好像不太合适吧？如果我们采用再创一个模块（framework）把上述的配置放进这个模块，这样设计是合适的吗？比如说：我想使用自定义redisTemplate，那么需要我们自己配置redisTemplate，然后再定义工具类，如果我采用上面的方式：配置redisTemplate配置类放进framework模块，工具类和依赖放进common模块。如果我想要使用common里的redis工具类，那是不是还要引入framework模块呢？这样做合理不？
问题二：多模块的配置扫描问题，假设我设置一个api模块，这个模块放置其他模块的controller，只有这一个模块具有application启动类。这个启动类只能扫描启动类同级和子级的包，那么他能不能扫描到其他模块的配置类或者service或mapper呢？是需要我自己定义路径吗？
感觉回答还可请采纳，谢谢
问题一：在多模块项目中，如何处理非公共代码是一个常见的问题。通常情况下，你可以按照功能或者模块的划分来组织代码。
对于你提到的依赖和配置的问题，可以考虑以下几种方式：
如果某个配置或依赖只在一个特定的模块中使用，可以将其放在该模块中。例如，如果你在使用minio的模块中需要引入依赖和创建bean，可以将相关的配置类和bean定义直接放在该模块中。类似地，对于sa-token的配置和拦截器注册，也可以放在特定的模块中。
如果某个配置或依赖在多个模块中都需要使用，你可以考虑创建一个专门的模块来存放这些共享的配置和依赖。这个模块可以被其他模块依赖，并提供对这些共享代码的访问。
在你的示例中，如果你想使用自定义的redis工具类，可以将redisTemplate配置类放在framework模块中，然后将工具类和依赖放在common模块中。当你需要在common模块中使用redis工具类时，只需要将common模块依赖于framework模块即可。
这种方式可以使得共享的配置和依赖更加清晰和可管理，同时也能避免不必要的依赖关系。
问题二：多模块项目的配置扫描问题需要根据具体的技术框架来处理。通常情况下，你可以在应用程序的启动类中配置扫描路径来确保其他模块的配置类、服务和映射器等能够被扫描到。
以Spring Boot为例，可以使用@ComponentScan注解指定需要扫描的包路径，你可以在启动类上使用该注解，将其他模块的包路径都包含进去。例如：
@SpringBootApplication
@ComponentScan(basePackages = {"com.example.api", "com.example.module1", "com.example.module2"})
public class Application {
// ...
}
这样配置后，Spring Boot会扫描指定路径下的组件，包括其他模块中的配置类、服务和映射器等。
具体的配置方式可能会因你使用的框架或构建工具而有所不同，你需要查阅相关框架的文档以获取准确的配置方法。
总结起来，你可以根据功能和模块的划分来组织代码和配置，使用模块化的方式将公共代码和功能封装起来，并通过配置方式确保需要扫描的组件能够被正确加载和使用。
配置类 可以跟着 你的具体业务模块走，比如你是 商品管理的，那配置类就可以放到 商品管理模块的 config目录里，或者实体类就可以放到 bean目录等等
如果是存配置数据，也可以新建一个配置模块出来。
application启动类 所在目录正常来讲是要依赖其他的模块的， 然后 扫描可以基于一些 特定的包路径 ，比如 xxx.service , xxx.mapper 等等