Lenguaje ubicuo: conflicto entre corrección y usabilidad

10

Una parte central del diseño impulsado por dominio es el uso constante de un lenguaje ubicuo en todo el sistema: en conversaciones, código, esquema de base de datos, interfaz de usuario, pruebas, etc.

Estoy involucrado en un proyecto en el que ya existe un lenguaje de dominio bien establecido, definido por una organización internacional de estándares.

Sin embargo, el trabajo que estamos haciendo es para un sitio web público, y los términos "correctos" para el dominio no son necesariamente la forma en que el público los usa y entiende típicamente.

El compromiso que estamos usando en este momento es usar los términos 'oficiales' en todas partes, excepto en nuestros criterios de aceptación que se refieren a los componentes de la interfaz de usuario, donde usamos los nombres informales.

¿Esto parece un enfoque razonable?

documentation domain-specific-languages

— Andy Waite
fuente

¿Puedes dar un ejemplo? Podría dar una respuesta más detallada entonces. ¿Necesita circunscribir términos para ellos o hay términos en conflicto con significados totalmente diferentes? ¿Sería posible encontrar un terreno común entre los términos informales y el idioma del dominio?

— Falcon

1

Ha pasado un tiempo desde que leí esa parte del libro de Evans, pero pensé que el lenguaje omnipresente debía usarse con el experto en dominio. Ciertamente, no esperaría que un usuario entienda toda la terminología del experto en dominios, por lo que solo le presentaría al usuario lo que ha denominado los nombres informales.

— Kaleb Pederson

7

Sí, eso parece razonable. Si la audiencia destinataria no comprende los términos de su idioma o los malinterpreta, entonces la usabilidad para el usuario final tiene prioridad.

Un programa o contenido que un usuario típico no comprende tiene poco valor. Más aún, si solo desea presentarles una punta simplificada de un iceberg porque no son y nunca serán expertos en dominios.

Normalmente, cuando se habla del dominio durante el desarrollo, todos entienden el lenguaje porque es preciso y todas las personas están dentro del dominio. Pero si el valor comercial se crea mediante la comunicación de contenido a personas externas al dominio, entonces haga esto de la manera más simple posible. Use palabras e idiomas que tengan menos probabilidades de ser mal interpretados y úselos en la interfaz de usuario.

Mantenga el lenguaje preciso en su código y para comunicarse con las personas que están preocupadas por el dominio. Estas son las personas que tienen las especificaciones y quienes son los usuarios clave de las aplicaciones, con quienes discuten los detalles lógicos del negocio. En el raro caso de que realmente discuta la mayoría de los detalles lógicos del negocio con usuarios que no tienen mucha idea sobre el dominio y no necesita profundizar en él, luego incorpore su idioma en el idioma de su dominio, dado que tener un lenguaje común e inequívoco (que probablemente no sea el caso).

Pero asegúrese de que los desarrolladores frontend conozcan sus términos informales y sus términos de dominio correspondientes.

— Halcón
fuente

1

Creo que la forma más fácil de responder a esto sería dibujar una línea exactamente donde la dibujarías si presentaras la interfaz de usuario en un idioma completamente diferente.

Si sus usuarios finales necesitaran ver cosas en sánscrito, ¿cómo cerrarían la diferencia entre la interfaz de usuario y el código (y otras comunicaciones internas)?

— John Fisher
fuente

Bien dicho. Esto señala el "problema de Humpty-Dumpty": las palabras no son solo una sustitución, sino que se refieren a cosas que las personas saben independientemente de las palabras y su uso. Los animales entienden la idea de "temperatura", por ejemplo. Nos obsesionamos con las palabras, cuando son solo símbolos de conceptos. Los conceptos son las cosas importantes.