您觉得本文档还缺少什么内容？可以自己补充~
认证服务： bc-oauth
主要包括 登录接口、获取用户权限接口、常用数据接口(如前端获取的字典、枚举接口）等接口和功能。
租户服务： bc-tenant
主要包括 租户管理、租户管理员维护、 租户表结构初始化、租户表数据初始化 等功能。
权限服务： bc-authority
主要包括 组织机构管理、岗位管理、租户下的用户管理、系统设置、权限配置等功能。
文件服务： bc-file
主要包括 文件存储、文件下载、文件回显等功能。支持第三方OSS存储。
网关服务： bc-gateway
主要包括 token解析、用户uri权限拦截、限流等功能。
bc-cloud 目录结构
├── 01-docs # 文档
│ ├── nacos # 项目需要的nacos配置
│ ├── sql # 数据库脚本
├── bc-authority # 权限服务
│ ├── bc-authority-api
│ ├── bc-authority-biz
│ ├── bc-authority-controller
│ ├── bc-authority-entity
│ └── bc-authority-server
├── bc-file # 文件服务
│ ├── bc-file-api
│ ├── bc-file-biz
│ ├── bc-file-controller
│ ├── bc-file-entity
│ └── bc-file-server
├── bc-gateway # 网关服务
│ └── bc-gateway-server
├── bc-oauth # 认证服务
│ ├── bc-oauth-api
│ ├── bc-oauth-biz
│ ├── bc-oauth-controller
│ └── bc-oauth-server
├── bc-public # 公共模块
│ ├── bc-common
│ ├── bc-common-api
│ ├── bc-file-sdk
├── bc-tenant # 租户服务
│ ├── bc-tenant-biz
│ ├── bc-tenant-controller
│ ├── bc-tenant-entity
│ └── bc-tenant-server
└── src
└── main
└── filters
└── config-dev.properties # 开发环境全局配置
└── config-prod.properties # 生产环境全局配置
项目结构介绍
概念声明
层：
API层： 包含bc-authority-api、bc-file-api、bc-msg-api 、bc-oauth-api 等模块
- 业务层：包含bc-authority-biz、bc-tenant-biz、bc-file-biz、bc-msg-biz 、bc-sms-biz、bc-oauth-biz等模块
- 控制层：包含bc-authority-controller、bc-tenant-controller、bc-file-controller、bc-msg-controller 、bc-sms-controller、bc-oauth-controller等模块
- 实体层：包含bc-authority-entity、bc-tenant-entity、bc-file-entity、bc-msg-entity 、bc-sms-entity等模块
启动层：包含bc-authority-server、bc-tenant-server、bc-file-server、bc-msg-server 、bc-sms-server、bc-oauth-server等模块
模块： (模块和层可以混着说, 知道团队的人懂即可)
bc-util 项目下的每个包. 如 bc-core、 bc-cloud-starter
bc-cloud 项目下的每个包. 如bc-authority-api、bc-common等
服务:
认证服务：bc-oauth下的所有模块组成权限服务
- 租户服务：bc-tenant下的所有模块组成租户服务
- 权限服务：bc-authority下的所有模块组成权限服务
- 文件服务：bc-file下的所有模块组成文件服务
- 网关服务：bc-gateway下的所有模块组成网关服务
- 消息服务：bc-msg下的所有模块组成消息服务
监控服务：bc-monitor
bc-public 目录下存放 业务服务公共模块 ：
bc-common 模块用于存放跟大多数服务有关的常量类和工具类等
- bc-common-api 模块公共api层
- bc-file-sdk: 附件sdk，用于业务服务保存和查询业务附件信息
总结： 一个服务可以包含多个模块，一个模块可以包含多个层。 比如：权限服务包含 租户模块和权限模块， 权限模块包含api层、业务层、控制层、实体层、启动层， 但租户模块没有api层和启动层， 因为租户模块是依赖权限模块的用户相关接口的，若独立成租户服务，会涉及跨服务访问，故合并成一个服务。
疑问🤔️
都已经是微服务项目了, 为什么还要将项目按模块拆封得如此细?
- 按照大功能将代码物理拆分成多个模块后, 强制按照server -> controller -> biz -> entity 层的依赖关系来开发功能
- 可以让项目结构更加清晰, 是典型的低耦合、高内聚体现;
- 可以避免开发水平参差不齐的团队,胡乱添加依赖, 胡乱注入Bean. (只允许: Controller 调用 Service, Service调用Mapper)
- 当某个项目不需要功能时(如没有站内信、没有短信发送、没有操作日志等), 按模块拆分的短信和站内信可以很轻松的在消息服务排除或者删除这2个功能, 而想要排除操作日志功能,必须得在权限服务一个类一个类的删除或注释, 异常的麻烦.
服务拆分模块建议
原则上推荐一个服务最好包含5个模块(api模块、entity模块、biz模块、controller层、server层), 但任何事情都不是绝对的,具体怎么分模块可以根据业务自身情况来定. 如: 消息服务希望将站内消息、短信、邮件等相关等逻辑集成到消息服务, 这几个功能既有独立性, 做得更细一些,甚至可以将站内消息、短信、邮件等功能独立成单独的服务, 但这务必会增加系统部署开销, 所以综合考虑, 将站内消息、短信、邮件等功能按模块开发,然后组合成一个服务, 即降低了部署等成本,也将每个功能独立出来,方便日后独立成单独的服务和禁用某些功能.
API层 说明：
服务于服务之间互相访问时，通过api模块来调用。api 模块实际上就是通过声明式FeignClient实现的接口，B服务调用A服务的UserApi接口时，FeignClient将该次调用封装成Http请求， 最后访问的是A服务的 Contoller层接口。
业务层 说明：
主要存放Servce接口及实现，Redis操作类、Mapper接口以及Xml（resources目录下）。 约定如下：
AService 能注入BServce，但禁止直接或间接循环注入。如AService -> BService ，BService->AService 在Service 层封装 业务逻辑, 操作缓存接口、Mapper接口的操作
实体层 说明：
存放实体po、文件传输对象DTO(本项目忽略VO)、枚举类型等，不涉及逻辑的一些类。
控制层说明：
主要存放一些服务的 Contrller 接口， 用于对外访问。 约定如下：
Controller 不能互相注入调用（我不说，真有人这么干！） Controller 只能调用Service，禁止调用Mapper(Dao) Controller 主要负责参数验证、转换等操作，尽量别写业务代码
启动层说明：
主要存放一些服务所需的启动类、配置类、配置文件、消息队列消费方监听入口等
每个层的依赖关系：
每个服务一般情况下都包含5个层： server、controller、biz、entity、api （特殊情况可以删减一些），他们的依赖依赖关系为： server -> controller -> biz -> entity ，api层独立，用于其他服务依赖。