Go engineering structure


1、 Description of key structural points:

(1) . project backbone: / CMD

The directory name of each project should match the name of the executable you want, for example: / CMD / myapp. Do not place too much code in this directory. If the code can be imported into other projects, it should be placed in the / PKG directory. If your code is not reusable or you don’t want others to reuse it, you should put it in the / internal directory.

(2) , private applications and code bases: / internal

This is because you don’t want others to import code into their applications or libraries. This layout is executed by the go compiler itself. It should be noted that the internal directory is not limited to the top-level directory, but can also be created under other directories. Additional structures can be added to the internal directory to separate shared and unshared internal code. This is not necessary (especially for smaller projects), but it is best to have visual clues to show the intended use of the package. The code of actual applications can be placed in the / internal / APP directory (for example: / internal / APP / myapp), and the code shared by these applications can be placed in the / internal / PKG directory (for example: / internal / PKG / myprovilb). Because we are used to integrating related services, such as account services, with RPC, job, admin, etc. after integrating related services, we need to distinguish apps. / internal / myapp can be removed from a single service.

(3) . library code used by external programs: / PKG

Library code that can be used by external programs (for example: / PKG / mypubliclib). Other projects will import these libraries, so you should be careful what you put here/ In the PKG directory, you can refer to the organization mode of go standard library and classify it according to function/ Internal / PKG is generally used for public shared code across multiple applications within a project, but its scope is only within a single project.

Note: the internal directory is a better way to ensure that private packages cannot be imported, because it is enforced by go. The / PKG directory is still a good way to explicitly represent that the code in the directory can be used safely by others

Go engineering structure

(4) . project basic library: / Kit

Each company should create a unified kit kit project (basic library / framework) and app project for different microservices. The basic library kit is an independent project, and only one is recommended at the company level. Splitting according to the function directory will bring a lot of management work, so it is recommended to merge and integrate.
Kit project must have the following characteristics:
Standard library layout
Highly abstract
Support Plug-Ins
Go engineering structure