La capa de dominio es la razón de ser de cualquier sistema bajo arquitecturas limpias, y entender cómo protegerla determina si tu software será reutilizable o se volverá un nudo difícil de mantener. Aquí encontrarás los errores más frecuentes al modelar el dominio, ejemplos concretos de cuándo lo estás vulnerando y un mapa de las formas más usadas para organizarlo.

¿Qué es el dominio y por qué es la pieza central del sistema?

El dominio representa lo que el negocio debe hacer exista o no un sistema de información. Por eso lo vas a encontrar nombrado de varias formas y todas significan lo mismo en la práctica.

¿Qué es la lógica de negocio? Es el conjunto de reglas, cálculos y decisiones que tu negocio necesita ejecutar sin importar la tecnología disponible. Lógica de negocio, lógica de dominio y dominio son sinónimos.

Piensa en un supermercado. Calcular descuentos o verificar inventario son tareas que hacen parte del dominio porque ocurren con o sin software. En cambio, si los empleados procesan ventas desde una app web o desde una consola, o si usan lectores de código de barras asignados a ciertas personas, eso pertenece a la capa externa o de infraestructura, porque puede cambiar sin afectar la regla del negocio [00:46].

¿Cuáles son los errores frecuentes al implementar la capa de dominio?

Estos son los tropiezos que aparecen una y otra vez, incluso cuando ya tienes experiencia con este tipo de arquitecturas.

¿Por qué no debes referenciar la capa externa desde el dominio?

El primer error es importar explícitamente algo de la capa externa dentro del dominio [02:23]. Por ejemplo, un servicio de dominio que hace import de un objeto Correo ubicado en infraestructura. Ahí ya rompiste el encapsulamiento.

La regla de dependencia es clara: siempre va de afuera hacia adentro, nunca al revés. El dominio no conoce a la infraestructura; la infraestructura conoce al dominio.

¿Cómo se filtra la infraestructura cuando no hay imports explícitos?

Este es más sutil. No tienes un import que delate el problema, pero usas terminología que pertenece a la capa externa.

Mira este caso: una función notificarUsuario que arranca creando una variable llamada enviarSMS. Aunque no importaste nada, ya estás asumiendo en el dominio que la notificación será un mensaje de texto [03:23]. Ese detalle no debería vivir ahí, porque mañana puedes cambiar a WhatsApp, correo electrónico o una red social. El dominio dice "notifica al usuario"; la infraestructura decide el medio.

¿Por qué no debes retornar datos atados a una interfaz específica?

Retornar desde el dominio un mensaje envuelto en una etiqueta <span> HTML te ata a un único tipo de cliente [04:43]. Si mañana ese mismo dominio alimenta una aplicación de escritorio o móvil, el HTML estorba.

Mejores alternativas para retornar resultados desde el dominio:

• Un booleano cuando solo necesitas indicar si algo existe o se cumple.
• Una enumeración cuando hay un conjunto cerrado de estados posibles.
• Un valor constante o un número que represente un código interno.

Lo que retornes debe ser independiente del formato visual.

¿Cómo evitar que la lógica de negocio se filtre a la interfaz?

Este es el error más difícil de manejar. Imagina un formulario con un botón "Guardar usuario" y, dentro del manejador del clic, terminan ocurriendo cosas que no deberían estar ahí [05:50].

Ejemplos típicos de lógica que se escapa al frontend:

• Validar coherencia entre dos campos del formulario, como un dropdown que condiciona otro valor.
• Verificar contra base de datos si el usuario ya existe.
• Decidir si la operación es un insert o un update.

Si todo eso vive en la interfaz, no podrás reutilizar ese formulario en otra aplicación. La recomendación es que el botón se limite a validar campos requeridos y reglas puramente visuales, mientras el dominio se queda con las reglas del negocio, incluida una validación equivalente más robusta.

¿Cuál es la diferencia entre validación de interfaz y validación de dominio? La de interfaz revisa formato y campos requeridos para mejorar la experiencia del usuario. La de dominio revisa reglas de negocio y debe existir aunque la interfaz cambie.

¿Cuáles son las formas de organizar el dominio en arquitecturas limpias?

Existen varios enfoques que se profundizan más adelante en el módulo, y cada uno encaja mejor según la complejidad del negocio [07:34]:

1. Script de transacción: organiza la lógica en procedimientos secuenciales, ideal para flujos sencillos.
2. Modelo de dominio: enfoque fuertemente orientado a objetos, donde el comportamiento vive con los datos.
3. Capa de servicios: complemento natural del modelo de dominio para coordinar operaciones.
4. Casos de uso: ya mencionados en clean architecture, encapsulan intenciones del negocio.
5. CQRS: separa lecturas y escrituras, común en arquitecturas limpias avanzadas.

¿Cuál de estos errores has visto con más frecuencia en tu equipo? Cuéntame en los comentarios qué prácticas te han funcionado para mantener el dominio bien protegido.