Un Domain-Specific Language (DSL) es un lenguaje de programación o de modelado cuyo diseño está intrínsecamente ligado a un dominio de aplicación específico, a diferencia de un General-Purpose Language (GPL) como Java o Python. Los DSLs se caracterizan por su expresividad concisa y su capacidad para abstraer detalles técnicos irrelevantes para el dominio, permitiendo a los expertos del dominio (que no necesariamente son programadores) definir reglas, configuraciones o comportamientos de manera más intuitiva y menos propensa a errores. Pueden ser externos (External DSLs), con su propio parser y sintaxis, o internos (Internal DSLs), implementados como una API fluida o una biblioteca dentro de un GPL existente.
La implementación de DSLs es ubicua en sistemas complejos. Ejemplos concretos incluyen SQL para la gestión de bases de datos relacionales, CSS para la estilización de documentos web, o Terraform HCL (HashiCorp Configuration Language) para la infraestructura como código. En el ámbito de la automatización, lenguajes como Jenkinsfile (Groovy-based DSL) o GitHub Actions YAML definen pipelines de CI/CD. Incluso herramientas de análisis de datos como R o lenguajes de consulta como GraphQL pueden considerarse DSLs para sus respectivos dominios. La creación de DSLs internos es común en frameworks como Spring (para configuración) o en bibliotecas de testing (como Mockito o Hamcrest) para definir expectativas de manera declarativa.
Para un Arquitecto de Sistemas, la elección o diseño de un DSL es una decisión estratégica con importantes trade-offs. Un DSL bien diseñado puede mejorar significativamente la productividad, reducir la complejidad cognitiva para los usuarios del dominio, aumentar la legibilidad y mantenibilidad del código, y facilitar la validación y la generación de código. Sin embargo, su desarrollo y mantenimiento pueden ser costosos, requiriendo herramientas específicas (parsers, IDEs) para External DSLs, o un diseño cuidadoso para Internal DSLs que evite la sobrecarga del GPL subyacente. El arquitecto debe evaluar si la complejidad del dominio justifica la inversión en un DSL, considerando el tamaño del equipo, la vida útil del sistema y la necesidad de empoderar a los expertos del dominio, balanceando la flexibilidad de un GPL con la expresividad y seguridad de un lenguaje específico.