El secreto mejor guardado para programar con IA: Diseño Orientado al Dominio

Cuando tu Asistente de IA No Puede Leer tu Mente

Seamos honestos: en algún momento te has frustrado con los asistentes de código basados en IA. Pides una funcionalidad y lo que obtienes técnicamente funciona, pero no captura lo que realmente necesitas. Nombres de clases genéricos. Lógica desperdigada en clases auxiliares. Un desprecio total por las reglas de negocio que hacen especial a tu aplicación.

Aquí está la verdad incómoda: la IA no es el problema. Tú lo eres.

No de forma acusatoria, sino práctica. Los modelos de lenguaje son espectaculares encontrando patrones y generando código, pero están limitados por lo que les das. Si le das a una IA contexto vago, obtendrás código vago. Si le das instrucciones ambiguas, obtendrás comportamiento ambiguo.

Aquí es donde entra el Domain-Driven Design (DDD), y sinceramente, es lo mejor que le ha pasado al desarrollo asistido por IA desde que existe el autocompletado.

Qué Es Realmente el DDD (Sin la Carga Académica)

Ya sé lo que estás pensando: "¿DDD? ¿Ese método pesado con 47 patrones y un libro azul de 800 páginas?"

Sí y no.

El DDD es fundamentalmente una apuesta sobre dónde vive la complejidad en el software. La premisa: en la mayoría de las aplicaciones, lo difícil no es la tecnología, sino entender y modelar el dominio. Las reglas de negocio, la terminología que aquí significa algo específico pero allá no, los casos límite que solo tienen sentido en su contexto.

Entonces el DDD dice: pon un modelo de tu dominio en el centro de tu trabajo. Expresa ese modelo en un lenguaje que entiendan tanto los desarrolladores como los responsables de negocio. Haz que el código refleje ese modelo directamente.

La parte estratégica abarca el panorama completo: establecer un vocabulario compartido (llamado Lenguaje Ubicuo) y definir límites (Contextos Delimitados) donde ese lenguaje se mantiene consistente.

La parte táctica abarca los bloques de construcción: entidades que tienen identidad, objetos de valor definidos por sus atributos, agregados que agrupan objetos relacionados, y eventos de dominio que capturan cambios significativos.

El anti-patrón al que debes prestar atención, y este confunde incluso a desarrolladores experimentados, es el "modelo anémico". Eso ocurre cuando tus objetos son simplemente bolsas de datos con getters y setters, mientras toda la lógica real vive en clases de servicio separadas. El DDD se opone firmemente a esto: pon el comportamiento donde están los datos.

Por Qué Esto Importa para los Asistentes de Código con IA

Aquí es donde se pone interesante para nosotros en 2024 y más allá.

Los modelos de lenguaje son esencialmente motores de completado de patrones acelerado. Predicen cómo debería verse el código basándose en lo que han visto en sus datos de entrenamiento. Y aquí está el problema: esos datos están llenos de patrones CRUD anémicos, nombres genéricos y lógica desperdigada. Ese es el camino de menor resistencia en la mayoría de los proyectos, así que eso es lo que los modelos usan por defecto.

Cuando usas principios de DDD, básicamente estás proporcionando rieles que guían a la IA hacia mejores resultados. Cada artefacto DDD que creas se convierte en material de prompt. Cada decisión que haces explícita se convierte en una restricción dentro de la cual la IA puede trabajar.

Déjame explicarte los cuatro lugares donde esto importa más:

1. Tu Vocabulario Compartido Se Convierte en el Prompt de Sistema de la IA

Imagina esto: estás construyendo un sistema de gestión de suscripciones. Tu equipo ha acordado que "suscripción," "plan" y "derecho" significan cosas muy específicas. Una suscripción es una relación activa entre un cliente y un plan. Un plan define qué está disponible. Un derecho es lo que el cliente realmente puede usar.

Cuando escribes una historia de usuario o una descripción de funcionalidad usando estos términos precisos, la IA puede internalizar ese vocabulario. Si le pides que añada una característica para "actualizar suscripciones," generará código que respeta estas distinciones. No mezclará "plan" y "derecho" porque has sido explícito sobre sus roles separados.

Ese glosario que mantienes para integrar nuevos desarrolladores también es exactamente lo que la IA necesita. La misma información, doble propósito.

2. Los Contextos Delimitados Mantienen las Sesiones de IA Enfocadas

¿Alguna vez has intentado que una IA ayude con una funcionalidad que toca seis partes diferentes de tu sistema? Los resultados suelen ser un desastre: cambios parciales, dependencias perdidas, lógica que se contradice entre módulos.

Los contextos delimitados resuelven esto de forma natural. Cada contexto es un área definida donde aplican un modelo y lenguaje particular. Cuando trabajas en el contexto de "Facturación," el término "cuenta" podría significar algo diferente que en el contexto de "Gestión de Usuarios." Eso está bien, siempre que los límites estén claros.

Para flujos de trabajo con IA, esto se mapea perfectamente en sesiones enfocadas. "Hoy trabajamos en el contexto de Cumplimiento de Pedidos. Aquí está su vocabulario y sus reglas. Ignora el contexto de Inventario por ahora." Así es como consigues que el modelo se mantenga enfocado en lugar de expandirse por todo tu sistema.

3. Los Modelos Ricos en Comportamiento Protegen Tus Reglas de Negocio

Este es el beneficio práctico de seguridad que a menudo se pasa por alto.

Cuando pones las reglas de negocio dentro de los objetos que poseen los datos relevantes, hay un solo lugar para protegerlas. Cuando distribuyes esas reglas entre varias clases de servicio, cualquier pedazo de código generado puede accidentalmente evadirlas.

Considera una regla de validación de pedido: un pedido no puede enviarse si el pago no se ha confirmado. Si esa regla vive en Pedido.Enviar(), está protegida. Cualquier código que intente enviar un pedido impago pasa por esa verificación. Pero si la regla vive en un ServicioEnvio separado, una IA que genere código podría crear alegremente un nuevo ProcesadorEnvio que envía pedidos sin verificar el estado de pago.

Los modelos ricos en comportamiento concentran tus invariantes en lugares donde realmente pueden proteger el sistema.

4. Las Pruebas Se Convierten en Especificaciones Ejecutables

El énfasis del DDD en invariantes, reglas que siempre deben cumplirse, se traduce directamente en casos de prueba. "Una suscripción no puede renovarse después de haber sido cancelada." "Un usuario no puede transferir más créditos de los que tiene disponibles." "Un pedido no puede enviarse a una dirección incompleta."

Estos no son solo buenas pruebas. Son una definición de corrección que una IA puede usar. Escríbelas primero y la IA tiene un objetivo concreto contra el cual programar. Puede ejecutar las pruebas y saber inmediatamente si va por buen camino. Esto es mucho más confiable que esperar que siga descripciones en prosa de las reglas de negocio.

Las Trampas a las Que Debes Prestar Atención**

Quiero ser directo contigo: usar DDD con IA no es magia automática. Los valores por defecto trabajan en tu contra de formas específicas.

La IA usa por defecto modelos CRUD anémicos. Si pides "una clase Cliente," a menudo obtendrás un par de getter/setter públicos con toda la lógica exiliada a un servicio separado. Tienes que pedir explícitamente comportamiento en el objeto, setters privados y lógica que viva con los datos que protege.

La IA inventa vocabulario. Tú dices "pedido," ella escribe "transacción." Tú dices "suscripción," ella escribe "membresía." Estos no son sinónimos en tu dominio, pero la IA no lo sabe a menos que se lo digas. Un vocabulario consistente y explícito en tus prompts ayuda, pero también lo hace poner esos términos en nombres de archivos, nombres de clases y comentarios donde la IA los recogerá naturalmente.

La IA sobre-diseña cuando tiene incertidumbre. Cuando una IA no tiene guía clara sobre el nivel correcto de complejidad, a menudo recurre a patrones elaborados, fábricas abstractas, interfaces excesivas, capas innecesarias. El DDD proporciona una heurística útil aquí: usa los patrones costosos (agregados, eventos de dominio, contextos delimitados) solo cuando la complejidad del dominio los justifica. Para dominios más simples, clases ricas en comportamiento con nombres claros podrían ser todo lo que necesitas.

La Conclusión Práctica**

Aquí está mi valoración honesta después de pensar en este patrón: el DDD ya no es principalmente una metodología de codificación. Es una metodología de ingeniería de contexto para la era de la IA.

Cada práctica de DDD que adoptas hace tu dominio más explícito, y explícito es exactamente lo que los modelos de lenguaje pueden usar. El vocabulario compartido que construyes para tu equipo se convierte en el vocabulario que la IA usa. Los contextos delimitados que trazas se convierten en unidades naturales de trabajo para sesiones de IA enfocadas. Los modelos ricos en comportamiento que creas se convierten en espacios protegidos donde las reglas de negocio no pueden ser evadidas silenciosamente.

Ibas a hacer este trabajo de todas formas, si querías software mantenible. Ahora también genera dividendos con los asistentes de IA.

Las partes económicas del DDD, claridad del lenguaje y concentración del comportamiento, aplican en todas partes. Las partes costosas, patrones tácticos completos, event sourcing elaborado, aplican solo donde la complejidad del dominio genuinamente los justifica.

Empieza con las partes económicas. Haz el vocabulario explícito. Pon comportamiento con los datos. Mantén los límites claros. Después deja que la IA te ayude a implementar el resto.

Tu yo del futuro, depurando código a las 2 de la mañana, te lo agradecerá. Y también la IA que realmente logra ayudar en lugar de entorpecer.