Comencé a programar usando Golang de verdad este año (2022), y lo que hice inmediatamente fue buscar referencias sobre cuál sería la mejor manera de evolucionar mi estructura para el proyecto. Este post será sólo uno de muchos otros que hablan sobre el mismo tema, y ​​quizás por eso decidí escribirlo.

En primer lugar, golang ya es completamente diferente en la forma en que trata las carpetas/paquetes y, para mejorar, tiene una esencia muy obstinada, con muchos documentos oficiales que informan cuál sería la forma "goway" de hacer algo (completa o no tocar), sin embargo, en la forma en que organizas tus archivos y carpetas, no hay realmente una dirección, por lo que cada uno da su propia interpretación del mundo a esta parte.

Dividiré esta publicación en 3 referencias y luego mostraré cómo resultó la combinación de estas referencias en el proyecto.

Primera referencia

Un sistema complejo que funciona invariablemente evolucionó a partir de un sistema simple que funcionó.
-- Ley de Gall

Para aplicaciones pequeñas, la estructura del proyecto debe ser simple.

Segunda referencia

La “comunidad” realizó una encuesta de un conjunto de patrones de diseño históricos y emergentes comunes en el ecosistema Go. Hay muchas cosas interesantes en esta encuesta, pero lo que me llamó la atención fueron las carpetas /cmd e /internal.

/cmd

Principales aplicaciones de este proyecto.
El nombre del directorio de cada aplicación debe coincidir con el nombre del ejecutable que desea tener (por ejemplo, /cmd/myapp).

/interno

Aplicación privada y código de biblioteca. Este es un código que no desea que otros importen a sus aplicaciones o bibliotecas. Tenga en cuenta que este patrón de diseño lo impone el propio compilador de Go.

Tercera referencia

Arquitecturas que separan mejor los “detalles” de lo que realmente aporta valor.

Resultado

Para una aplicación simple, trato de mantenerla simple, sin embargo, cuando el alcance se hace un poco más grande, trato de hacer una ligera diferenciación entre lo que es “núcleo”/dominio y lo que es detalle/infraestructura.

Tenga en cuenta que en cmd no tengo la carpeta tuttipet, como sugiere el proyecto de referencia. Al principio intenté usar el patrón sugerido, pero como esta API ya venía con una interfaz de línea de comandos y un proveedor para terraform, decidí dejarlo así.

Acerque rápidamente el núcleo. Intento ser simplista aquí y no crear carpetas. Solo mantengo 1 punto de contacto con el mundo externo (main.go), lo que se generaliza tiene su propio archivo y lo que no se queda dentro de su contexto, simple.

Con tuttipet.Nuevo (breve, conciso y evocador) la capa “sucia” puede interactuar con los casos de uso (la palabra caso de uso me parece más fácil de asimilar que interactor)

Acerque rápidamente los detalles. Estas son simplemente las herramientas mediante las cuales el dominio logrará su éxito.

Conclusión

Todavía soy débil en el camino que ofrece Golang, todavía estoy tratando de descubrir qué se puede hacer con él, sin embargo, aunque no me gusta la forma en que Go hace algunas cosas, ha demostrado ser bastante simple y robusto.

Resumen, tratando de mantenerlo simple cuando sea posible y si se vuelve demasiado complejo... volveré a la mesa de dibujo.

otras referencias

https://dev.to/booscaaa/implementando-clean-architecture-com-golang-4n0a
https://github.com/golang-standards/project-layout
https://blog.boot.dev/golang/golang-project-structure/
https://github.com/bnkamalesh/goapp
https://www.wolfe.id.au/2020/03/10/how-do-i-structure-my-go-project/
https://blog.logrocket.com/flat-structure-vs-layered-architecture-structuring-your-go-app/
https://developer20.com/how-to-structure-go-code/
https://dev.to/jinxankit/go-project-structure-and-guidelines-4ccm
https://github.com/bxcodec/go-clean-arch
https://golangexample.com/example-go-clean-architecture-folder-pattern/
https://www.calhoun.io/flat-application-structure/
https://go.dev/doc/efectivo_go#nombres
https://go.dev/blog/nombres-paquetes

Publicación original: https://medium.com/@espigah/go-layout-do-projeto-18aacce8089d