Go微服务框架go-kratos月卡实战(二)上一节，我们基于 kratos-layout 创建了基础的服务，接下来先看

上一节，我们基于 kratos-layout 创建了基础的服务，接下来先看下基础的项目布局

kratos 项目布局

项目的目录结构图如下：

我们服务的主要逻辑都要在internal目录里面完成 internal目录包含 biz、data、service、server、conf 。

biz：上图里说了类似 DDD 的 domain 层，也就是 DDD 架构中的领域层。这里还定义了对业务操作的接口。业务逻辑组装。
data：对数据库 db，缓存 cache 的封装，并且实现 biz 中定义的接口。它将领域对象重新拿出来，这里去掉了 DDD 的基础层。
service：实现 api 定义的服务层，类似 DDD 的应用层。处理数据传输对象到 biz(领域实体)的转换。同时协同各类 biz 交互，不应处理复杂逻辑。
server：http 和 grpc 实例的创建和配置，以及注册对应的 service。
conf:是配置文件的proto定义。

API 与用户的通信协议，通常是 REST API 和 RPC API 作为传输层协议，而 Kratos 主要参考 Google API 指南，实现了对应通信协议支持，并且遵守了 gRPC API 使用 HTTP 映射功能进行 JSON/HTTP 的支持。

也就是通过定义 proto 即可使用 REST API 和 RPC API，通过类似 Google API 的仓库方式进行 API Schema 的管理。

在 kratos 中，API 指的是 REST API 和 RPC API ，REST API 是用户访问应用程序时的入口，RPC API 作为应用程序内部相互访问的接口定义。

那怎么定义 API？使用的是 protocol-buffers 这种与编程语言无关的接口自定义语言(IDL)，它可以根据定义的 pb 来生成你所需的编程语言程序。

gRPC 是 Go 语言编写的一个开源的 RPC 框架，它使用的 IDL 就是 protocol-buffers。

protocol-buffers 语法学习可以参考文档：