Go layout do projeto de engenharia

Estou participando do "Programa Nuggets · Sailing"

Se você está tentando aprender Go, ou está construindo um Poc ou um projeto de brinquedo para si mesmo, este layout de projeto não é necessário, comece com algo simples (um arquivo principal é mais que suficiente). Quando mais pessoas estão envolvidas no projeto, você precisa de mais estrutura, incluindo a necessidade de um takeit para facilitar a geração de modelos de projeto e um layout de diretório de projeto unificado o máximo possível.

Este artigo gira em torno do github.com/golang-stan…

/cmd

A espinha dorsal deste projeto. O nome do diretório de cada aplicativo deve corresponder ao nome do executável que você deseja (por exemplo: /cmd/myapp)

Não coloque muito código neste projeto, se você acha que o código é importado e usado em outros projetos, então ele deve estar no /pkgdiretório, se o código não for reutilizável, ou você não quer que outros o reutilizem, coloque o código no /internaldiretório.

/interno

Para código que não deseja ser compartilhado com o mundo externo , internalalgumas estruturas de subpacote também podem ser colocadas no diretório, que foi dividido em mais detalhes, como:

|--internal
|   |
|   |--demo
|       |--biz
|       |--data
|       |--service
复制代码

/pacote

Bibliotecas de código que podem ser usadas por aplicativos externos (por exemplo: /pkg/publiclib) Outros projetos irão importar essas bibliotecas de código, então você deve pensar duas vezes sobre o código colocado neste diretório~ Nota: O /internaldiretório é um método privado para garantir que pacotes privados não podem ser importados, pois são aplicados pelo Go em tempo de compilação. /pkg ainda é uma maneira melhor de representar explicitamente o código em um diretório que é seguro para outros usarem.

/pkgNo diretório, você pode consultar a forma organizacional da biblioteca padrão GO. Ela é classificada de acordo com as funções. Geralmente /internal/pkgé usada para código compartilhado comum dentro de um projeto e em vários aplicativos, mas seu escopo é apenas dentro de um único projeto.

|--pkg
|  |
|  |--cache
|  |   |--memcache
|  |   |--redis
|  |
|  |--conf
|      |--dsn
|      |--env
|      |--flagvar
|      |--paladin
复制代码

/docs,/example,/pkg,/third_parth,/tools

Estes são os mesmos que os acima /pkge /internalpertencem à estrutura de diretórios sob o diretório raiz

• /docs coloca alguma documentação do projeto
• /example coloca alguns exemplos de uso do projeto
• /thrid_parth Alguns arquivos dependentes das três partes, como: arquivo idl
• /tools coloca algumas ferramentas de scaffolding de projeto, ferramentas de geração de código, etc.

Layout básico do projeto de biblioteca

Toda empresa deve criar um conjunto de ferramentas de base de kit unificado para diferentes microsserviços. A biblioteca básica é um projeto independente, há apenas uma recomendação em nível de empresa. Dividir por funções trará muito trabalho de gerenciamento, portanto, é recomendado e integrado.

Características que um kit deve ter

1. Unir
2. Layout de biblioteca padrão
3. altamente abstrato
4. Suporte a plug-ins

Por exemplo, o seguinte layout

|--cache
|    |--memcache
|         |--test
|    |--redis
|         |--test
|--conf
|    |--dsn
|    |--env 
|    |--flagvar
|    |--paladin
|          |--apollo
|               |--internal
|                     |--mockserver
|--container
|    |--group
|    |--pool
|    |--queue
|         |--aqm
|--database
|    |--hbase
|    |--sql
|    |--tidb
|--echo
|    |--types
|--log
|    |--internal
|         |--core
|         |--filewriter
|
复制代码

Layout do projeto do aplicativo

/api

Diretório de definição de protocolo da API, arquivo protobuf xxapi.proto e o arquivo que gera go, geralmente definimos o documento api no arquivo proto para descrever

/configs

Modelo de arquivo de configuração ou configuração padrão

/teste

Aplicativos de teste externos adicionais e dados de teste, você sempre pode estruturar o diretório de teste de acordo com suas necessidades, para projetos maiores faz sentido ter um subdiretório de dados, por exemplo, você pode usar /test/testdata (se precisar ignorar o diretório em content) Observe que o Go também possui diretórios ou arquivos que começam com "." ou "_", por isso é conveniente e flexível em como nomear o diretório de dados de teste.

não deve conter o diretório /src

Alguns projetos Go têm um diretório src porque os desenvolvedores geralmente têm experiência em Java.

/interno

/nós

A camada de montagem da lógica de negócios, semelhante ao domínio em DDD,

/dados

O acesso a dados de negócios, incluindo o encapsulamento de cache e db, implementa a interface repo do biz, podemos misturar dados e dao, os dados focam no significado do negócio, o que ele faz é retirar os objetos do domínio novamente, removemos a infra camada de DDD,

/serviço

Implementada a camada de serviço definida pela api, semelhante à camada applocation do DDD, que trata da conversão de DTO para entidades de domínio biz, (DTO->DO) os colegas interagem com cada classe biz, mas não devem lidar com lógica complexa

diagrama de layout

|--api
|--configs
|--test
|--internal
|       |--biz
|       |--data
|       |--service
复制代码

fluxo de dados