基础知识
1.项目架构
1.图示
2.说明
1. sunrays-dependencies
- 职责：管理项目的依赖版本及配置。
- 描述：独立模块，不继承其他模块。
2. sunrays-framework
- 职责：统一管理整个项目，继承
sunrays-dependencies。 - 描述：作为项目的核心框架模块，负责整体项目的基础配置和管理。
3. sunrays-common
- 职责：封装通用组件，继承
sunrays-framework。 - 描述：包括一些通用的工具类、公共模块等。
4. sunrays-common-cloud
- 职责：封装 Cloud 相关的通用组件，继承
sunrays-framework。 - 描述：包括 Cloud 相关的基础设施和服务封装。
5. sunrays-common-demo
- 职责：提供
sunrays-common和sunrays-common-cloud的测试 demo，继承sunrays-framework。 - 描述：用于验证
sunrays-common和sunrays-common-cloud子模块的功能和集成。
6. sunrays-combinations
- 职责：管理业务依赖，或者作为中台，继承
sunrays-framework。 - 描述：通过组合
sunrays-common和sunrays-common-cloud完成具体的业务依赖管理。
7. sunrays-combinations-demo
- 职责：提供
sunrays-combinations模块的测试 demo，继承sunrays-framework。 - 描述：用于验证
sunrays-combinations模块的功能和集成。
2.common-log4j2-starter说明
1.这个模块是必须被引入的！
2.对于sunrays-combinations
如果引入了sunrays-combinations模块的依赖，就不需要额外引入common-log4j2-starter，因为已经默认包含了。
3.对于sunrays-common或者sunrays-common-cloud
如果引入的是sunrays-common或者sunrays-common-cloud，那么就需要额外引入common-log4j2-starter。
3.隐私数据保护的问题
1.引入common-env-starter
这个依赖一旦引入，就可以在application.yml配置文件中配置.env文件的路径，然后通过$占位符来从.env文件中读取隐私数据，我在后面的介绍中都会采用这种方式。
2.不引入common-env-starter
在实际开发中，如果不需要进行隐私数据的保护，就可以不引入这个依赖：
- 不需要在application.yml配置文件中配置.env文件的路径，也不需要创建.env文件了
- 将我示例中的${xxx}的部分直接替换为真实的数据即可，比如：
