DDD: Lenguaje ubicuo vs lenguaje publicado

Para hacer esta pregunta de la manera más breve posible: ¿pueden ser diferentes?

Antecedentes: Vlad Khononov en su excelente libro 'Learning Domain-Driven Design (2021)' escribe (p55):

La interfaz pública del proveedor no pretende ajustarse a su lenguaje ubicuo. En cambio, se pretende exponer un protocolo conveniente para los consumidores, expresado en un lenguaje orientado a la integración.

En cierto sentido, el patrón de servicio de host abierto es una inversión del patrón de la capa anticorrupción: en lugar del consumidor, el proveedor implementa la traducción de su modelo interno.

Mientras que Olaf Zimmerman en un gran artículo (2021) ( https://eprints.cs.univie.ac.at/6948/1/europlop21-s16-camera-ready2.pdf ) escribe:

Pero para que la API sea comprensible para los expertos en dominios, es esencial que los nombres y las abstracciones en la API sigan los términos definidos en el lenguaje ubicuo que se especifica formalmente en el modelo de dominio.

Creo que la respuesta a la pregunta sería SÍ: es posible usar diferentes términos en el lenguaje publicado y en el lenguaje ubicuo para el mismo elemento de dominio. En el modelo de dominio, registra la diferente terminología aplicando 'alias': un alias denota el término de idioma publicado utilizado para un elemento en el modelo de dominio que se nombra de acuerdo con el idioma ubicuo del contexto acotado correspondiente.

¿Qué piensas?

Solución del problema

La pregunta es cuánta traducción deben hacer los desarrolladores (internos y externos) entre los términos de la API frente a las palabras de UL. Casi siempre es una compensación, que se forma con el tiempo a medida que evolucionan el producto y su API.

Todos estos patrones son aceptables y efectivos a su manera:

Una API amigable para el consumidor que a veces se desvía de UL

Una API que refleja los términos de UL en las API, lo que garantiza que las partes interesadas internas y externas compartan la misma vista del contexto delimitado

Una capa de traducción que asigna la API externa fácil de usar para el consumidor a la terminología interna de UL a través de alias

Administrar una API externa significa menos margen de maniobra si descubre cambios de terminología. En lugar de tratar de conservar los términos tal como están, el Enfoque 3 lo ayuda a mejorar la UL interna y al mismo tiempo proteger la santidad de la API.

Puede comenzar con el Enfoque 2 de manera predeterminada y esforzarse por retenerlo, pero esté abierto a recibir orientación de aportes externos y enfoques de cambio.