1024programmer Java Detailed explanation of creating Go engineering project layout

Detailed explanation of creating Go engineering project layout

Table of contents
  • Text
    • /cmd
    • / internal
    • /pkg
    • /docs,/example,/pkg,/third_parth,/tools
    • Basic library project layout
      • Features that the kit package should have
  • Application project layout
    • /api
      • /configs
        • /test
          • Should not contain the /src directory
          • /internal
            • /biz
              • /data
                • /service
                • Layout diagram
                  • Data flow


                  If you are trying to learn Go, or you are building a POC or a toy project for yourself, this project layout is not necessary, start with something simple (a main file is more than enough). When more people participate in this project, you will need more structures, including a toolit to facilitate the generation of project templates and a unified project directory layout for everyone

                  This article focuses on github.com/golang-stan…


                  The backbone of this project. The directory name of each application should match the name of your desired executable file (for example: /cmd/myapp)

                  Don’t put too much code in this project, if you think the code is imported and used in other projects, then it should be located in the /pkg directory, if the code is not reusable, or If you don’t want others to reuse it, please put the code in the /internal directory.


                  For code that is not expected to be shared externally, some sub-package structures can also be placed in the internal directory to achieve more detailed segmentation, such as:

                   | |
                   | |--demo
                   | |--biz
                   | |--data
                   | |--service


                  Code libraries that can be used by external applications, (for example: /pkg/publiclib) other projects will import these code libraries, so you should think twice about the code you put in this directory ~ Note: /internalDirectory is a private way to ensure that private packages are not importable, since it is enforced by Go at compile time. /pkg is still a better way to explicitly represent that the code in a directory is safe for others to use.


                  /pkg directory can refer to the organizational form of the GO standard library, which is classified according to function. /internal/pkg is generally used within projects and across multiple applications. Code is shared publicly, but its scope is only within a single project.

                   | |
                   | |--cache
                   | | |--memcache
                   | | |--redis
                   | |
                   | |--conf
                   | |--dsn
                   | |--env
                   | |--flagvar
                   | |--paladin


                  These are the same directory structures under the root directory as the /pkg and /internal mentioned above

                  • /docs Place some project documentation
                  • /example Place some project usage examples
                  • /thrid_parth Some third-party dependency files, such as: idl files
                  • /tools places some project scaffolding tools, code generation tools, etc.

                  Basic library project layout

                  Every company should establish a unified kit base package tool set for different microservices. The basic library tookit is an independent project. It is recommended that there be only one at the company level. Splitting it according to functions will bring a lot of management work, so it is recommended to integrate it

                  Features that kit packages should have

                  • Unified
                  • Standard library layout
                  • Highly abstract
                  • Support plug-ins

                  For example the following layout

                   | |--memcache
                   | |--test
                   | |--redis
                   | |--test
                   | |--dsn
                   | |--env
                   | |--flagvar
                   | |--paladin
                   | |--apollo
                   | |--internal
                   | |--mockserver
                   | |--group
                   | |--pool
                   | |--queue
                   | |--aqm
                   | |--hbase
                   | |--sql
                   | |--tidb
                   | |--types
                   | |--internal
                   | |--core
                   | |--filewriter

                  Application project layout


                  API protocol definition directory, xxapi.proto protobuf file and the file that generates go. We usually define the api document and describe it in the proto file


                  Configuration file template or default configuration


                  For additional external test applications and test data, you can always construct the test directory according to your needs. For larger projects, it makes sense to have a data subdirectory, for example you can use /test/testdata (if�The contents of the directory need to be ignored) Please note that Go will also include directories or files starting with “.” or “_”, so it is convenient and has great flexibility in how to name the test data directory.

                  /src directory should not be included

                  Some Go projects do have a src directory. This is because developers usually have a Java development background.



                  The assembly layer of business logic, similar to domain in DDD,


                  Business data access, including cache and db encapsulation, implements biz’s repo interface. We may mix data and dao together. Data focuses on business meaning. What it does is to take out domain objects again. We removed the infra layer of DDD,


                  Implements the service layer defined by the API, which is similar to the applocation layer of DDD. It handles the conversion of DTO to biz domain entities. (DTO->DO) colleagues collaborate with each other to interact with biz, but should not handle complex logic

                  Layout diagram

                   | |--biz
                   | |--data
                   | |--service

                  Data flow direction

                  The above is the detailed explanation of creating Go engineering project layout. For more information about Go engineering project layout, please pay attention to other related articles!

                  This article is from the internet and does not represent1024programmerPosition, please indicate the source when reprinting:https://www.1024programmer.com/768477

                  author: admin

                  Previous article
                  Next article

                  Leave a Reply

                  Your email address will not be published. Required fields are marked *

                  Contact Us

                  Contact us


                  Online consultation: QQ交谈

                  E-mail: [email protected]

                  Working hours: Monday to Friday, 9:00-17:30, holidays off

                  Follow wechat
                  Scan wechat and follow us

                  Scan wechat and follow us

                  Follow Weibo
                  Back to top