¿La evidencia actual respalda la adopción de modelos contextuales sobre modelos canónicos?

La idea "canónica" es generalizada en el software; patrones como el modelo canónico , el esquema canónico , el modelo de datos canónico , etc., parecen aparecer una y otra vez en el desarrollo.

Como muchos desarrolladores, a menudo he seguido, sin crítica, la sabiduría convencional de que necesita un modelo canónico, de lo contrario, se enfrentará a una explosión combinatoria de mapeadores y traductores. O al menos, solía hacerlo hasta hace un par de años, cuando leí por primera vez el infame Voto sin confianza de EF :

Las hipótesis que una vez respaldaron la búsqueda de modelos de datos canónicos no incluyeron ni pudieron incluir factores que se descubrirían una vez que la idea se pusiera en práctica. Hemos descubierto, a través de años de prueba y error, que el uso de modelos separados para cada contexto individual en el que se podría usar un modelo de datos canónicos es el enfoque menos complejo, el enfoque menos costoso y el que conduce a una mayor capacidad de mantenimiento y extensibilidad de las aplicaciones y puntos finales utilizando modelos contextuales, y es un enfoque que no fomenta la entropía del software que hacen los modelos canónicos.

El ensayo no presenta evidencia de ningún tipo para respaldar sus afirmaciones, pero me hizo cuestionar el enfoque del MDL el tiempo suficiente para probar la alternativa, y el software resultante no explotó, literal o figurativamente. Pero eso no significa mucho aislamiento; Podría haber tenido suerte.

Entonces, me pregunto, ¿se ha realizado alguna investigación seria sobre los efectos prácticos a largo plazo de tener un modelo canónico versus modelos contextuales en un sistema o arquitectura de software?

O, si es demasiado pronto para preguntar eso, ¿tiene algún desarrollador / arquitecto escrito sobre experiencias personales que cambien de un MDL a modelos contextuales independientes, o viceversa, y cuáles fueron los efectos prácticos en cosas como la productividad, la complejidad o la confiabilidad?

¿Qué pasa con las diferencias en los diferentes niveles, es decir, usar el mismo modelo en una sola aplicación versus usarlo en un sistema de aplicaciones o en toda una empresa?

(Solo hechos, por favor; las historias de guerra son bienvenidas pero no se especulan).

En respuesta al artículo del voto de no confianza de EF , Tim Mallalieu escribe:

No recomendamos que la gente regrese a los días en que evangelizamos el uso de XSD para "esquemas canónicos". No creo que la gente piense que esto es manejable. Sin embargo, lo que sí creemos es que es deseable tener un solo metamodelo (EDM si lo desea) con el que pueda describir muchos modelos de dominio y que al tener una gramática única podemos proporcionar un conjunto de servicios comunes en cualquier modelo de dominio dado

Por ejemplo, considere una aplicación que se escribirá en una base de datos con 600 tablas. ¿Creo que esta aplicación debería tener un solo modelo con 600 tipos de entidad? No ... Además, ¿creo que una entidad de dominio determinada (por ejemplo, Cliente) tiene una sola forma en esa aplicación y que esta debe ser la forma canónica para toda la empresa? ... Diablos, no.

El artículo de Wikipedia para Canonical Model hace referencia a cosas como Enterprise Service Bus , Service-Oriented Architecture y CORBA , cosas de las que parece que ya casi no se habla. Todos se presentaron como la solución a la proliferación de datos y los desafíos de comunicación de la empresa, el Anillo Único para Gobernarlos a Todos. ^TM ¿Tuvieron éxito? ¿O colapsaron bajo su propio peso?

Solicitaste experiencias personales, así que te daré una. En la industria aeroespacial, utilizamos mucho la telemetría. Uno de los desafíos con los sistemas de telemetría es encontrar una manera para que los diferentes rangos de prueba comuniquen los datos de prueba entre sí de manera significativa. Ese problema parece bastante simple, hasta que intentas definir un diccionario de datos de términos comunes.

¿Qué significa "altitud"? ¿Es la altura sobre el suelo, o es la altura sobre el nivel del mar? ¿Qué pasa si estás hablando de un submarino? Entonces su profundidad, no altitud. Para el Ejército, la palabra "transmisión" tiene un significado diferente cuando se refiere a un plato de radar que a un vehículo terrestre. La superficie del ala que hace que un avión ruede se llama "alerón" en algunos aviones y "elevon" en otros.

Eso es solo una pista de la montaña de problemas que siguen. Aunque existen estándares para las comunicaciones de datos, cada rango de prueba es diferente y tiene diferentes necesidades, objetivos y prioridades. Los estándares pueden diferir incluso entre diferentes proyectos en el mismo rango. Por esta razón, los rangos de prueba entienden que la solución no vendrá reemplazando todo con un único sistema monolítico, sino acordando protocolos de comunicación simples y proporcionando formas de traducir el vocabulario de un rango a otro.

Los problemas que enfrentan las grandes empresas son similares. Microsoft tiende a pensar en términos monolíticos, pero eso se debe a que su compañía es, en general, monolítica. Tan pronto como necesite comunicarse entre diferentes compañías con culturas y formas de hacer negocios muy diferentes (o incluso entre departamentos dispares en la misma compañía), el Anillo único para gobernarlos a todos. ^TM inmediatamente comienza a descomponerse.