Ir al diseño del proyecto de ingeniería

Estoy participando en el "Programa de Vela · Nuggets"

Si está tratando de aprender Go, o está construyendo un Poc o un proyecto de juguete para usted, este diseño de proyecto no es necesario, comience con algo simple (un archivo principal es más que suficiente). Cuando hay más personas involucradas en el proyecto, necesita más estructura, incluida la necesidad de un takeit para facilitar la generación de plantillas de proyecto y un diseño de directorio de proyecto unificado tanto como sea posible.

Este artículo gira en torno a github.com/golang-stan…

/cmd

La columna vertebral de este proyecto. El nombre del directorio de cada aplicación debe coincidir con el nombre del ejecutable que desea (por ejemplo: /cmd/myapp)

No ponga demasiado código en este proyecto, si cree que el código se importa y se usa en otros proyectos, entonces debería estar en el /pkgdirectorio, si el código no es reutilizable o no quiere que otros lo reutilicen, poner el código en /internalel directorio.

/interno

Para el código que no desea compartirse con el mundo exterior , internaltambién se pueden colocar algunas estructuras de subpaquetes en el directorio, que se ha dividido en más detalles, como:

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

/paquete

Bibliotecas de códigos que pueden ser utilizadas por aplicaciones externas (por ejemplo: /pkg/publiclib) Otros proyectos importarán estas bibliotecas de códigos, por lo que debe pensar dos veces sobre el código colocado en este directorio ~ Nota: El /internaldirectorio es un método privado para garantizar que Los paquetes privados no se pueden importar porque Go lo impone en tiempo de compilación. /pkg sigue siendo una mejor manera de representar explícitamente el código en un directorio que es seguro para que lo usen otros.

/pkgEn el directorio, puede hacer referencia a la forma organizativa de la biblioteca estándar GO. Se clasifica según las funciones. Generalmente /internal/pkgse usa para código común compartido dentro de un proyecto y en múltiples aplicaciones, pero su alcance es solo dentro de un solo proyecto.

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

/docs,/ejemplo,/paquete,/tercera parte,/herramientas

Estos son los mismos que los anteriores /pkgy /internalpertenecen a la estructura de directorios bajo el directorio raíz

• /docs poner algo de documentación del proyecto
• /example coloca algunos ejemplos de uso del proyecto
• /thrid_parth Algunos archivos dependientes de las tres partes, como: archivo idl
• /tools coloca algunas herramientas de andamiaje de proyectos, herramientas de generación de código, etc.

Diseño de proyecto de biblioteca básica

Cada empresa debe crear un conjunto de herramientas de base de kit unificado para diferentes microservicios. La biblioteca básica tomó es un proyecto independiente. Solo hay una recomendación a nivel de empresa. Dividirla según las funciones traerá mucho trabajo de gestión. Por lo tanto, se recomienda e integra.

Características que debe tener un kit

1. Unir
2. Diseño de biblioteca estándar
3. muy abstracto
4. Soporte de complementos

Por ejemplo, el siguiente diseño

|--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
|
复制代码

Diseño de proyecto de aplicación

/api

Directorio de definición de protocolo API, archivo protobuf xxapi.proto y el archivo que genera go, generalmente definimos el documento api en el archivo proto para describir

/configs

Plantilla de archivo de configuración o configuración predeterminada

/prueba

Aplicaciones de prueba externas adicionales y datos de prueba, siempre puede estructurar el directorio de prueba según sus necesidades, para proyectos más grandes tiene sentido tener un subdirectorio de datos, por ejemplo, puede usar /test/testdata (si necesita ignorar el directorio en contenido) Tenga en cuenta que Go también tiene directorios o archivos que comienzan con "." o "_", por lo que es conveniente y flexible en cómo nombrar el directorio de datos de prueba.

no debe contener el directorio /src

Algunos proyectos de Go tienen un directorio src porque los desarrolladores suelen tener experiencia en Java.

/interno

/nosotros

La capa de ensamblaje de la lógica empresarial, similar al dominio en DDD,

/datos

El acceso a datos comerciales, incluida la encapsulación de caché y db, implementa la interfaz de repositorio de biz, podemos mezclar datos y dao, los datos se enfocan en el significado de los negocios, lo que hace es sacar los objetos del dominio nuevamente, eliminamos la infraestructura. capa de DDD,

/Servicio

Se implementó la capa de servicio definida por la api, similar a la capa de aplicación de DDD, que maneja la conversión de DTO a entidades de dominio comercial, (DTO->DO) los colegas interactúan con cada clase comercial, pero no deben lidiar con una lógica compleja.

diagrama de diseño

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

flujo de datos