Esta tarde estuve haciendo rubber ducking con Claude Opus 4 para revisar un patrón que veo una y otra vez en bases de código modernas, con o sin Ports and Adapters, Hexagonal u Onion: la ausencia de una capa anticorrupción.
Un ejemplo real que dispara esta conversación es la típica pregunta de cómo convertir entidades a DTO. Suena a sopa de patrones, pero merece ir al grano porque el problema es de diseño, no de moda arquitectónica.
Imagina una respuesta de un servicio back end que no podemos modificar. Suele venir como un objeto tipo interface UserDTO con propiedades como user_name opcional, user_age como string, email_address opcional y created_at como number que en realidad representa una fecha. Y sí, a menudo todo es opcional, así que a veces llega un objeto vacío.
El pro de los tipos es que puedes construir toda tu app alrededor de ellos. El contra es exactamente el mismo. Cuando los tipos externos son débiles o inconsistentes, terminas con violaciones de la filosofía parsea, no valides, validaciones en tiempo de ejecución desperdigadas por varios módulos, múltiples parseos de fecha y reglas de email repetidas, controles de opcionalidad por todas partes y retornos raros que acaban contaminando todo el código. Los tests sufren con fixtures extraños que rompen cada vez que el contrato cambia y nadie sabe qué es un valor razonable porque los tipos no lo son.
La gente de Domain Driven Design propuso una solución clara: la Anti Corruption Layer, o ACL. La idea es simple y potente: proteger tu dominio para que los tipos sucios ajenos no lo corrompan. Tus reglas de negocio y tus tipos expresivos del dominio deben permanecer limpios, y el borde con los sistemas externos debe contener la complejidad.
Cómo se aplica en la práctica. En OOP defines un DTO que representa los datos del exterior, un VO u objeto de valor que representa los datos con los que quieres trabajar en tu dominio y una clase mapper que convierte de DTO a VO, operación que puede fallar si algo no cuadra, y de VO a DTO, operación que no debería fallar. En FP suele ser más directo: dos tipos y dos funciones puras, una que mapea unknown a un resultado tipo éxito o error, y otra que serializa tu tipo de dominio a un registro plano.
El guion típico en equipos de producto es este. El API devuelve JSON con un esquema laxo, el proveedor asegura que casi todo es opcional por restricciones heredadas y el equipo responde creando interfaces con todas las propiedades opcionales, tests con objetos vacíos y controles defensivos por todo el código. Aunque la explosión combinatoria de valores opcionales rara vez te golpea de lleno, el resultado es el mismo: código frágil y difícil de mantener.
La salida es disciplinada y concreta. Crea los tipos que quieres tener en tu dominio y haz que el mundo externo pase por tu ACL. Si los datos no son legítimos, falla temprano y de forma explícita en el borde, no después. Si el negocio acepta datos parciales, modela ese estado como un tipo distinto en lugar de llenar de opcionales tu VO. TypeScript te da uniones discriminadas y exhaustividad, aprovéchalas. Para la validación, usa herramientas como Zod o ArkType y evita hacer narrowing manual complejo; así documentas de forma verificable lo que aceptas y lo que rechazas. Esto mejora la conversación con producto y diseño porque puedes decir con precisión cuándo hay transacciones, cuándo la lista vacía es válida y cuándo hay un error.
Checklist rápido para llevar a tu equipo. 1. Define los tipos de dominio que deseas trabajar, tus VO. 2. Define los DTO que reflejan el contrato externo tal como es. 3. Implementa una ACL que convierta de DTO a VO, fallando cuando la entrada no cumple lo mínimo necesario, y de VO a DTO sin ambigüedades. 4. En OOP piensa en clases y mapeadores; en FP, en tipos más funciones puras. 5. Valida en el borde, no en el centro del dominio.
Cómo te ayuda Q2BSTUDIO. En Q2BSTUDIO diseñamos arquitecturas limpias para proyectos de software a medida y aplicaciones a medida, aplicando ACL, modelado de dominio y validación robusta para que tus equipos puedan moverse rápido sin romper. Si estás arrancando o escalando una plataforma, podemos acompañarte desde la definición del contrato hasta los pipelines de calidad, automatización de procesos y observabilidad.
Nuestros equipos combinan ingeniería y negocio para crear soluciones de ia para empresas, agentes IA y analítica avanzada. Integramos ciberseguridad desde el diseño, desplegamos en servicios cloud aws y azure y conectamos tus datos con servicios inteligencia de negocio y power bi para dar visibilidad al impacto de cada decisión.
Si tu producto necesita un núcleo sólido y tipos que de verdad representen tu dominio, podemos ayudarte a implantar una ACL bien diseñada dentro de una solución de software a medida que crece contigo. Y si buscas acelerar con modelos y automatización inteligente, explora nuestros servicios de inteligencia artificial aplicados a producto, datos y operaciones.
Conclusión práctica. Una ACL no es burocracia, es una inversión para mantener tu dominio limpio, hacer el código predecible y reducir el coste de cambios. Modela bien, valida en el borde, comunica estados con tipos expresivos y evita que la incertidumbre del exterior se cuele en el corazón de tu sistema. Buena caza ahí fuera.