DDD

La forma en que integras un LLM en tu aplicación depende fundamentalmente de quién tiene el control: ¿tu código decide el flujo y el LLM solo responde, o el LLM decide qué hacer a continuación? Esta distinción te lleva a dos patrones arquitectónicos muy diferentes. Patrón 1: LLM como Infraestructura Cuando la interacción es sencilla —envías un prompt, recibes una respuesta— el LLM es infraestructura. Es un servicio externo más, como un servicio de traducción o de geocoding. ...

La instrumentación es esencial en cualquier aplicación: logs para debugging, métricas para monitorización y trazas para entender el flujo de ejecución. Pero cuando esta instrumentación se mezcla directamente en los casos de uso, el código se vuelve difícil de leer, mantener y especialmente, de testear. En este post exploraré un patrón que habitualmente aplico: abstraer la instrumentación detrás de interfaces específicas de dominio, manteniendo los casos de uso expresivos y enfocados en la lógica de negocio. Además, me facilita posponer decisiones de infraestructura y mejora dramáticamente la calidad de los tests. ...

En arquitecturas event-driven, es útil distinguir entre eventos según su propósito: comunicación dentro del dominio versus integración entre bounded contexts. Esta distinción ayuda a manejar mejor el acoplamiento y la evolución del sistema. El Contexto Cuando todo se modela como “un evento”, aparecen tensiones. Un mismo mensaje intenta servir a dos propósitos diferentes: Comunicar hechos del dominio para coordinar reacciones dentro del bounded context. Exponer cambios de estado como contrato de integración con otros bounded contexts. Por ejemplo, cuando un producto se pone a la venta en un e-commerce: ...