Resumen de Puntos Clave de Arquitectura

Cada viñeta destacada de las 9 páginas de esta sección, recopilada en una sola página y agrupada por la página de la que proviene.

Arquitectura en Go: Interfaces Pequeñas, Dependencias Explícitas

• Go recompensa las dependencias explícitas pasadas en los constructores sobre las globales y los singletons
• Defina interfaces en los puntos de llamada donde se consumen, no donde se declaran los tipos
• Acepte interfaces y devuelva structs concretos para minimizar el acoplamiento y facilitar la prueba
• Conecte todas las implementaciones concretas en main.go como la única raíz de composición
• Mantenga los paquetes de dominio independientes evitando importaciones de http, sql o SDK de proveedores
• Divida las interfaces según las necesidades del llamador para mantener los mocks honestos y reducir el acoplamiento innecesario

Conceptos Básicos de Arquitectura de Go

• Organice el código en cmd/ para binarios, internal/ para ocultar, pkg/ para paquetes compartidos
• Utilice la inyección de constructor para validar entradas y permitir que los llamadores controlen la configuración
• Defina interfaces en el consumidor, no en el proveedor, para facilitar las pruebas y la simulación
• Mantenga los manejadores HTTP delgados, traduzca al dominio, use el contexto para la cancelación, mapee errores
• Ponga la lógica de negocio en la capa de servicio entre HTTP y el almacenamiento, envuelva los errores para el contexto
• Aísle la persistencia detrás de las API del repositorio que devuelven tipos de dominio, no filas del controlador

Monolito vs Microservicios en Go

• Los monolitos de Go se implementan como binarios únicos más rápido que la gestión de la infraestructura de microservicios
• Divida los servicios cuando los equipos se bloqueen mutuamente semanalmente o los subsistemas necesiten escalado independiente
• Diseñe interfaces de paquetes que se conviertan en límites gRPC al dividir microservicios
• Los microservicios necesitan transacciones distribuidas como sagas y requieren sobrecarga de propagación de trazas
• Los límites de servicio en Go son opciones de implementación, no impuestas por el propio lenguaje
• Las llamadas en proceso y el registro unificado siguen siendo más rápidos cuando el rendimiento del monolito satisface las necesidades

Arquitectura Limpia y Hexagonal en Go

• Los puertos son interfaces que utiliza el dominio; los adaptadores los implementan
• Utilice este patrón cuando deba reemplazar la infraestructura sin reescribir las pruebas
• El código de dominio solo importa stdlib, nunca SQL, HTTP o frameworks
• Los servidores HTTP y gRPC son adaptadores de conducción que ingresan al sistema
• Las dependencias apuntan hacia adentro; las capas exteriores nunca dependen de las interiores
• Úselo cuando múltiples puntos de entrada compartan la misma lógica de negocio

Capas de Handler-Service-Repository

• Divida los adaptadores HTTP, la lógica de negocio y la persistencia en tres capas probables
• Las dependencias fluyen desde los manejadores a los servicios y a los repositorios, nunca hacia atrás
• Los manejadores traducen formatos de cableado y mapean errores de negocio a códigos de estado HTTP
• Los servicios validan entradas, aplican reglas de negocio y orquestan flujos de trabajo
• Los repositorios abstraen el acceso a datos a bases de datos, cachés y API externas
• Aplique cuando los manejadores tengan SQL, lógica de negocio larga o utilicen múltiples transportes

Inyección de Dependencias: wire, dig y Cableado Manual

• Prefiera el cableado manual en Go: es explícito y fácil de buscar de forma predeterminada
• Wire genera pegamento de constructor en tiempo de compilación a través de go generate
• dig y fx utilizan la reflexión para construir gráficos de objetos en el inicio en tiempo de ejecución
• Diseñe constructores e interfaces pequeños: las herramientas de DI no arreglan paquetes enredados
• Adopte la DI cuando main.go exceda la mantenibilidad o agregue subsistemas opcionales
• Wire detecta la obsolescencia en tiempo de compilación; dig y fx detectan problemas al inicio

Registros de Decisiones de Arquitectura para Equipos de Go

• Organice los servicios de Go como monolitos modulares, no como archivos main.go únicos
• Capas de manejadores, servicios y repositorios para mantener las pruebas amigables con simulaciones
• Componga dependencias explícitamente en main.go, no en variables globales init()
• Utilice net/http ServeMux para mantener los enrutadores HTTP en el borde del adaptador
• Prefiera gRPC con protobuf para la comunicación entre servicios
• Utilice consultas SQL explícitas, no ORM, para el acceso a datos del repositorio

Lista de Verificación de Refactorización y Auditoría de Arquitectura

• Reemplace el estado mutable global con inyección de constructor cableada al inicio
• Extraiga contratos compartidos o invierta dependencias para romper ciclos de importación
• Mueva los errores de inicialización de init() a main con un manejo de errores claro
• Mueva la lógica de negocio y la validación a los servicios, mantenga los manejadores delgados
• Cargue secretos y puntos finales desde el entorno o las banderas, nunca codificados
• Mueva las dependencias del framework de los paquetes de dominio a la capa del adaptador

Mejores Prácticas de Arquitectura y Diseño

• Defina interfaces en los consumidores, no en los proveedores, para dependencias flexibles
• Prohíba los ciclos de importación en el código de producción; señalan costuras arquitectónicas incorrectas
• Refactorice en rebanadas verticales para evitar reescrituras de gran tamaño y riesgo arquitectónico
• Mantenga los frameworks en el borde; los enrutadores y ORM no deben filtrarse en el código del dominio
• Envíe binarios estáticos desde CI para lograr consistencia desde el portátil hasta la producción
• Utilice context.Context para la cancelación en métodos de servicio y repositorio