Implementar Domain-Driven Development (DDD) en Go puede parecer sencillo en teoría. Sin embargo, cuando intentamos modelar algo tan fundamental como un Value Object, nos encontramos con una realidad distinta: Go no impone ciertas reglas de diseño que otros lenguajes orientados a objetos sí hacen, eso cambia completamente la conversación. Más que un problema técnico, se convierte en una decisión de gobernanza, disciplina y cultura de equipo.
Cuando un equipo decide trabajar con DDD, suele hacerlo buscando mayor claridad en el dominio, mejor modelado y reglas explícitas dentro del código, en lenguajes como Java, muchas de estas garantías están respaldadas por el propio lenguaje: constructores, visibilidad estricta, clases, herencia. Pero Go funciona diferente y cuando intentamos implementar Value Objects respetando sus invariantes e inmutabilidad, descubrimos algo interesante: el lenguaje no te protege automáticamente. Entonces la pregunta deja de ser ¿cómo lo implemento? y pasa a ser: ¿cómo garantizo que el equipo respete las reglas cuando el lenguaje no las impone?
Intentamos lo lógico:
Cada opción resolvía algo, pero rompía otra cosa.
El tipo público permitía creaciones inválidas fuera de la factory.
El tipo privado rompía la reutilización externa.
La interfaz introducía ambigüedad semántica.
Los linters dependían de herramientas que no siempre estaban maduras.
En teoría estamos modelando un simple username (nombre de usuario)
En la práctica estábamos definiendo cómo queríamos que nuestro equipo trabajara.
Ahí entendimos que el problema no era técnico: era de gobernanza.
Go es minimalista por diseño.
Eso significa que:
En otras palabras, en Go la arquitectura no termina en el código, se extiende a acuerdos internos, revisiones de PR y herramientas auxiliares.
Después de evaluar múltiples alternativas, tomamos una decisión pragmática:
No es perfecto, pero es coherente con nuestro contexto y eso es lo que realmente importa en ingeniería.
Implementar Value Objects en Go nos recordó algo fundamental: la arquitectura no depende únicamente del lenguaje, sino de cómo el equipo decide usarlo. Cuando el lenguaje no impone reglas, el diseño se convierte en un acto consciente, y la disciplina técnica pasa a formar parte activa de la arquitectura. Go × DDD no es una combinación problemática; es una combinación que exige criterio. En ingeniería, el criterio es esa capacidad de decidir cuándo aplicar una regla y cuándo no vale más que cualquier patrón.
