Idea principal

Una excepción llamada ElementAnnuléNonModifiable no es un mensaje de error: es una regla de negocio escrita en código, legible por un agente de soporte que no programa. Una excepción llamada InvalidStateException dice lo mismo al procesador y nada a nadie más. Es esa diferencia, y no la calidad técnica del repositorio, la que decide si una pregunta de producto puede encontrar allí su respuesta.

La condición se declina en toda la materia: entidades que llevan los nombres que emplean los usuarios, acciones cuyo enunciado se lee, eventos que cuentan lo que ha ocurrido, políticas que hacen visibles las reacciones en cascada, módulos cuya estructura es previsible. Un repositorio donde los conceptos del dominio se esconden tras nombres técnicos y donde las reglas están dispersas sigue siendo opaco, por mucho cuidado que se haya puesto en su división o en su cobertura de pruebas.

La exigencia es antigua —los enfoques de diseño dirigido por el dominio la sostienen desde hace tiempo— y no la crearon los asistentes. Un desarrollador que retoma un repositorio así paga la misma traducción permanente entre la necesidad de negocio y la mecánica del software; cada evolución obliga a reconstruir ese vínculo, cada búsqueda de una regla cuesta más. Lo que cambia con la posibilidad de interrogar el código es que ese defecto se vuelve medible desde fuera del equipo técnico: ya no se traduce en lentitud difusa, sino en respuestas que nadie puede obtener.

Por qué es importante

Esto desplaza el criterio que se aplica antes de instalar un dispositivo de consulta. La pregunta que hay que hacerle a un repositorio no es "¿está bien mantenido?", sino "¿está escrito allí el vocabulario del dominio?" — dos propiedades que a menudo coinciden y que no tienen vínculo necesario.

También da un argumento no técnico a una inversión que solo tenía uno. Renombrar conceptos hacia el lenguaje del negocio deja de ser una preferencia de artesano en cuanto el soporte, la preventa y el product management dependen de ello para obtener respuestas.

Matices y límites

La uniformidad no existe: un mismo repositorio habla el idioma del negocio en el módulo de facturación, escrito veinte años antes por gente que conocía el dominio, y se queda mudo en la capa de integración. La condición se verifica zona por zona, no sobre el repositorio entero.

El vocabulario inscrito en el código tiene además fecha. Un nombre de entidad que ha sobrevivido a tres reposicionamientos cuenta un negocio que ya no se practica, y su propia legibilidad lo vuelve engañoso.

Por último, un nombre de negocio correcto puede recubrir una regla falsa. Que una excepción exprese una regla la hace legible, no exacta: lo que se vuelve consultable es el código, no el producto deseado.

Preguntas abiertas

• ¿Quién arbitra el vocabulario cuando los usuarios llaman a un objeto de otra forma que el código, y ambos usos tienen quien los defienda en la empresa?
• ¿Con qué se mide, antes de emprender el trabajo, la distancia entre el vocabulario de un repositorio y el del dominio?