微服务项目代码结构

微服务项目代码接口

1.微服务代码结构

在实际的微服务开发中，我们常常这样来划分层次

tt-root
├── tt-auth -- 授权服务提供
├── tt-common -- 常用工具封装包
├── tt-gateway --  网关
├── tt-ops -- 运维中心
├    ├── tt-admin -- spring-cloud后台管理
├    ├── tt-develop -- 代码生成
├    ├── tt-resource -- 资源管理
├    ├── tt-seata-order -- seata分布式事务demo
├    ├── tt-seata-storage -- seata分布式事务demo
├── tt-service-provider -- 业务模块
├    ├── tt-desk-provider -- 工作台模块 
├    ├── tt-log-provider -- 日志模块 
├    ├── tt-system-provider -- 系统模块 
├    ├── tt-user-provider -- 用户模块 
├    ├── tt-order-provider -- 订单模块 
├         ├── entity(数据表字段映射实体类包)
├		  ├── dao(数据操作类包)
├		  ├── service(服务操作类包)
├		  ├── api(服务暴露实现类包)
├── tt-service-api -- 业务模块api封装
├    ├── tt-desk-api -- 工作台api 
├    ├── tt-dict-api -- 字典api 
├    ├── tt-system-api -- 系统api 
├    ├── tt-user-api -- 用户api 
├──  └── tt-order-api -- 订单api 
├		  ├── request(请求实体包)
├		  ├── response(返回实体包)
└──		  └── api (服务暴露接口包)

2.包依赖关系

举例：将order分为两个jar，一个是api包，另一个是provider包

• api包：主要存在服务接口的暴露，包括请求实体类和返回实体类，比较纯粹
• provider包：主要用于服务接口的实现，包括一些逻辑处理，类似我们传统web工程，是一个真正的服务处理工程

其中provider包依赖于api包，api包主要用于对外开放服务接口！

禁止出现以下依赖

这样子会导致在启动order服务或者user的时候，工程会报jar冲突，工程存在循环依赖的问题！

原因：order-api.jar包依赖user-api.jar然后user-api.jar又依赖order-api.jar，导致循环依赖！

正确的做法应该是由provider工程来依赖，而不是由api来依赖！