# 项目原则
- 坚持最小依赖，默认最佳实践，支持自定义，以实用为主；
- 项目以DDD架构为原型，提供开箱即用的功能。
# 技术选型
Java17+SpringBoot2.6+MyBatis|JPA+Hutool+Docker
# 项目分层
> 基础架构层 infrastructure
分为核心库和组件库，核心库是必须的，组件库根据需要选用，没有强制依赖。
infrastructure-core
-依赖javax系列，hutool系列，orika和slf4j，主要提供无依赖的基础类库，包括领域基类，转换类，异常类，帮助类，uuid生成器，供其他各层使用。
infrastructure-spring
-依赖spring各种starer，提供cache，json，jwt，redis等各种扩展和配置。
infrastructure-mybatis
依赖mybatis-mapper和mybatis，提供mybatis的基类，以及Mybatis扩展，包括对枚举类型的处理，对JPA的支持。
infrastructure-excel
-依赖easyExcel，提供对easyExcel的封装，方便导入和导出。
> 领域层 flower-domain
核心业务逻辑，建议使用富领域模型，仅依赖infrastructure-core。
领域仓储层 flower-repository
领域存储接口，仅仅是接口，具体实现根据技术选型决定，仅依赖domain层，实践中一般合并到领域层。
领域仓储有两个实现层，分别是：
flower-repository-mybatis
-通过mybatis实现数据库操作，Mapper通过继承MybatisMapper可以实现常用增上改查操作，我们只需要写复杂查询及特殊操作即可
flower-repository-jpa
-通过jpa实现数据获取和保存，对jpa使用没有任何限制。
> 应用层 flower-application
应用层，融合领域层和领域仓储层，常用套路：准备数据（通过领域仓储或外部服务获取数据） -> 执行操作（对象创建，赋值，领域处理，纯内存操作） -> 持久化（保存到仓储或发消息），依赖领域层和领域仓储接口层。
技术规范：
- 应用层应该永远返回Output（输入为Input），而不是Entity；
- 应用层不负责处理异常，遇到错误直接抛出异常是最合理的；
- 应用层只使用一个入参，入参是唯一的类型，不服用的类型；
> 接口层 flower-webapi
接口层主要对网络协议的转换，统一鉴权，限流配置，异常处理
- 对接口参数进行转换和验证，通过JSR303，<实战篇-基础设施，基类与配置>中有详细说明；
- 对接口输入和输出格式化，通过json格式，<实战篇-接口实现，配置和部署>中有详细说明；
- 统一鉴权，获取当前用户，以便传递给下游服务；
- 异常处理，接口层做统一异常捕获，避免将异常直接暴露给调用端，并转化为调用端可以理解的数据格式；
- 配置组件参数和环境变量；
- 配置具体领域仓储实现。
技术规范：
- 接口层返回值为ActionResult；
- 接口层捕获所有异常；
- 接口层负责处理所有参数校验；
实战篇-项目架构，原则和分层
实战篇-基础设施，基类与配置
实战篇-接口实现，配置和部署
实战篇-仓储技术选型
实战篇-工具类实战
