模块说明
模块介绍
blade树形结构（点击展开）
blade
├── blade-base # 基础包
│ ├── blade-common # 公共包 这里只是简单的组合了下面的core、logging-core、user、util本身并无代码
│ ├── blade-core # 核心包 注解、常量、枚举、异常类型、web出入参协议
│ ├── blade-logging-core # 一个kt风格的日志框架(第三方)
│ ├── blade-user # 用户包 用户信息、用户上下文、用户拦截器等
│ └── blade-util # 工具包 常用工具类
├── blade-dependencies # 第三方依赖版本和插件统一维护
└── blade-starters # 启动器starter的集合
├── blade-auth-spring-boot-starter # 用户认证
├── blade-data-mybatis-plus-spring-boot-starter # mybatis-plus
├── blade-data-redis-spring-boot-starter # redis集成包(遗留包)
├── blade-diagnostics-spring-boot-starter # 诊断信息
├── blade-feign-spring-boot-starter # 内部服务之间feign的一些配置
├── blade-file-spring-boot-starter # 文件处理及 OSS 上传
├── blade-gateway-spring-boot-starter # 网关功能扩展
├── blade-jimmer-spring-boot-starter # jimmer orm 集成包
├── blade-lock-spring-boot-starter # 分布式锁
├── blade-logging-spring-boot-starter # 日志
├── blade-mq-spring-boot-starter # 消息总线
├── blade-oss-path-convert-spring-boot-starter # oss路径转换
├── blade-oplog-spring-boot-starter # 操作日志集成
├── blade-sensitive-spring-boot-starter #序列化脱敏
├── blade-sequence-spring-boot-starter # 序列号、ID生成器
├── blade-tenant-spring-boot-starter # 租户相关的配置
├── blade-test-spring-boot-starter # 测试相关的配置
├── blade-versions-spring-boot-starter # 版本上报
├── blade-web-boot-spring-boot-starter # web相关的配置 这是个springboot项目的
├── blade-web-cloud-spring-boot-starter # web相关的配置 这是个springcloud项目的
├── blade-web-spring-boot-starter # web相关的常用配置
└── blade-xss-spring-boot-starter # xss过滤防护
架构概述
Blade框架采用分层架构设计，从下到上分别为基础模块层、启动器模块层和应用层。基础模块层提供了核心功能和工具类，启动器模块层通过Spring Boot的自动配置机制封装了各种功能，应用层则通过引入相应的启动器来使用这些功能。
模块层次结构
启动器模块
启动器模块是Blade框架的上层应用直接可以使用的功能，通过Spring Boot的自动配置机制，实现了功能的即插即用。
认证授权启动器
此次核心解决
blade此次在booster的基础上想要解决的核心问题:
- 易于组合
- 便于测试
易于组合
想象一下你去餐馆吃饭：
餐馆就餐流程（点击展开）
- 到达餐馆： 你到达餐馆后，通常会被服务员问候并引领到一张空闲的桌子。
- 查看菜单（重要性和可搭配性）： 服务员会提供菜单，这是整个就餐体验中至关重要的一部分。菜单不仅展示了餐馆提供的所有菜品和饮料，还是你了解食物种类、风味和价格的主要方式。 菜单通常会设计得直观易读，有时按照菜品类型（如前菜、主菜、甜点）或食材种类（如肉类、海鲜、素食）来组织。 餐馆可能会提供推荐搭配，帮助顾客选择互相补充的菜品，以获得更好的口味体验。例如，某些酒类可能会建议与特定的主菜搭配以增强风味。
- 点餐： 在浏览菜单并决定想要点什么之后，你会告诉服务员你的选择。在这个阶段，你可以询问服务员任何关于菜品的问题，比如成分、推荐搭配或特别推荐。 常见套餐策略： 许多餐馆会提供套餐，这是一种常见的策略，通过捆绑销售前菜、主菜和甜点或饮料来提供整体的价值感和便利性。 套餐通常会比单点菜品更具成本效益，因为它们通常设定了优惠价格。 套餐也是餐馆推广特色菜品或新菜品的一种方式，它们通常会包括最受欢迎或最具代表性的菜品组合。
- 等待上菜： 在点餐后，你可以等待菜品准备好并被逐个送到你的桌上。这是交谈或享用餐前饮料的好时机。
- 享用美食： 当菜品上桌后，你可以开始享受你点的食物。这是就餐体验的核心部分，你可以品尝不同的口味和搭配。
- 结账： 餐后，你可以请求账单。服务员会将账单带到你的桌上，你可以通过现金、信用卡或其他支付方式来支付。
- 离开餐馆： 支付完成后，你可以离开餐馆。在离开前，你可以对服务员表示感谢或给予小费，这取决于当地的习俗和你的个人偏好。
以前的项目上来说，对外只提供了一个starter供于业务开发使用，如果某一些功能不需要，可以通过config标志位开闭，所有的依赖、所有的功能所有的代码聚合在一起，耦合度偏高
借着上面的例子来类比：
这个餐馆有很多的食材(module)，但是菜单上只有一样菜品(大乱炖), 什么客户来了只有这一个菜品可以点，大乱饨：就是把所有食材都放在了一起炒，你说你想吃xx，不想吃xx, 你自己用筷子拨开你不想吃的，只夹你自己想吃的，但是这样仍然会串味 即使你知道这个餐馆的后厨拥有各式各样的原生食材，非常新鲜，但是你别无选择，厨师只会做这道菜给你， 除非~~~~~~ 你自己跑去后厨撩起衣袖自己炒
后来booster进行了拆分，以功能为侧重点进行拆分，使得每个底层实现都变得相较于以前清晰一些，进一步解耦了不相干的功能之间的工程依赖，底层都做了分拆，并且每一个实际都是starter，可以单独使用，不过还是有一些功能有了绑定，比如说：一些基于json库的功能：脱敏、xss防御、日志等
blade这次要解决的就是类似这样 2、3 的问题，将功能实现细拆化，像springboot一样提供单独的starter供于上层应用，**侧重组合 **
每一个模块都是实现的单一功能的成品，它就像每一个菜式，有自己独特的味道(功能) 可以单独使用 尽量不依附于任何平级module
如果一个项目需要的功能很多，可以像叠积木一样叠加依赖进入项目，这样就可以很方便的组合出自己想要的功能，也可以很方便的排除不需要的模块,如果不需要大可不必引用到依赖树中，徒增包大小。
如果一些功能犹如 葱姜蒜 一样的无敌常用组合，也可以像餐馆套餐一样，制定相应的bom依赖供于上层应用，这个所谓的bom就只是依赖的组合，并没有代码上面的依赖和耦合，而只是为了能够让上层应用的pom也会比较清爽，例如web-cloud
重要
底包有一个很重要的思想：引入就能使用，不需要再让使用者做额外的配置才能使用功能，使用者唯一需要思考的：就是要不要使用，如果确定不使用那就不用引入依赖
便于测试
在以前的工程中，要对某个具体的小功能进行独立测试总是不太方便，排查问题也相当困难，这使得实现“可测试性”成为一个挑战。通常需要关闭许多功能开关，在庞大的工程中进行测试，这样很难确保模块间没有相互干扰。同时，验证每个模块的可用性也不是件容易的事（特别是当你一次性对多个模块进行了更改并需要进行测试时）。
应这一需求，我们为每个模块提供了相应的集成使用示例 。在这些示例中，你可以独立地进行测试，不必担心受到其他自定义模块的干扰，或者至少将这种干扰降到最低。这样，你就能更轻松地评估某个组件是否符合你的预期、是否可用，或者你可以针对组件测试结果给维护者提出宝贵的反馈和建议。
"约定优于配置"是一种编程理念，它推崇预设的编程习惯而不是繁琐的配置，这样做可以减少开发者在软件开发过程中需要做的决策数量，从而简化开发工作，同时保持必要的灵活性。
这里需要提前说明的是，在我们的项目中，我们采用了配置中心nacos 来集中管理所有配置项。所以关于项目内部application.yml的配置文件几乎可以不修改，Blade框架会为每个模块提供一套默认配置，如果有自定义配置需求，可以直接在 nacos 中进行调整，或者选择在项目代码中直接硬编码这些配置。