Skip to main content

Project Structure

Layout DDD

The kratos-layout is used by command kratos new for new project creation. The directory structures and tool chains are included in this layout project. Which help you be more efficient in developing. This project could also considered as the best practice of building microservices with Go and Kratos. Layout

Project layout of a Service

├── api     // Includes .proto API files and the .go files which generated from them.
├── cmd // The entry point of the kratos app
│ └── main
│ ├── main.go
│ ├── wire.go // wire library is for dependency injection
│ └── wire_gen.go
├── configs // The configuration files for local development.
│ └── config.yaml
├── external
│ └── service // The external profo definition from other services.
│ └── external_service // Service name
│ └── external_module // Service module name

├── internal // All the codes which are private. Business logics are often exist in there, under "internal" directory for preventing from unwilling import.

│ ├── biz // The layer for composing business logics. It is similar to the domain layer in DDD. The interface of repo are defined in there, following the Dependence Inversion Principle.
│ │ ├── biz.go
│ ├── client
│ │ ├── client.go
│ │ └── external_service
│ ├── config // The structure for configuration parsing, generated from .proto file
│ │ └── config.proto
│ ├── data // For accessing data sources. This layer is mainly used as the encapsulation of databases, caches etc. The implementation of repo interface which defined in biz layer should be placed here. In order to distinguish from DAO (data access object), the data layer stress on business. Its responsibility is to transform PO to DTO. We dropped the infra layer of DDD.
│ │ ├── data.go
│ │ ├── migration // Database migration methods using Gorm
│ │ │ └── migration.go
│ ├── entity // Database models
│ ├── model // Business models
│ ├── server // The creation of http and grpc instance
│ │ ├── grpc.go
│ │ ├── http.go
│ │ └── server.go
│ └── service // The service layer which implements API definition. It is similar to the application layer in DDD. The transformations of DTO to DO and the composing of biz are processed in this layer. We should avoid to write complex business logics here.
│ ├── health.go
│ ├── providers.go
│ └── service.go
├── locale // Messages by message ids
├── third_party // Third party modules or proto files
└── xml // Query text manage by xml files