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

9

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).

Aaronaught
fuente
No tengo idea de lo que están hablando en el artículo "Voto sin confianza". El resto del artículo tiene sentido, pero la sección sobre canonicalismo es tan abstracta que no significa nada. Hubiera sido agradable si hubieran proporcionado un ejemplo de lo que estaban hablando.
Robert Harvey
@Robert: No tengo idea si hay algo de verdad en eso, pero me queda bastante claro lo que significa ... ¿seguramente estás familiarizado con los patrones CM / CDM? En su encarnación más simple, está compartiendo un solo modelo / contexto monolítico de EF (o Linq to SQL, o lo que sea) a través de toda la aplicación en lugar del enfoque más (percibido) basado en conductos de escribir consultas específicas para partes específicas de la aplicación. En un nivel superior, está adoptando un esquema universal para toda una organización al que deben traducirse todas las aplicaciones / sistemas individuales.
Aaronaught
1
Parece que el debate de EF se centra en el diseño de primera tabla versus primer clase, ya que el diseño de primera tabla (donde las clases se generan a partir de las tablas) sugiere un modelo monolítico (aunque siempre hay consultas y vistas especializadas), mientras que el diseño de primera clase (donde las tablas se generan a partir de las clases) sugiere un modelo OO más flexible y flexible. Soy un poco de la vieja escuela, prefiero el enfoque de primera mesa, pero pude ver cómo el enfoque de primera clase sería atractivo para algunos.
Robert Harvey
@Robert, no era mi intención mencionar el "debate de EF", solo tomé una cita de esa página porque fue donde escuché por primera vez el argumento (y no estoy seguro de haberlo escuchado) claramente expresado en cualquier otro lugar). Por separado, no estoy seguro de estar de acuerdo en que el diseño de primera mesa en realidad representa un modelo monolítico; la base de datos en sí lo es, pero solo el DBMS es realmente consciente de eso: las diferentes partes de la aplicación tienden a ser conscientes de las tablas y consultas específicas de las que dependen.
Aaronaught

Respuestas:

5

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.

Robert Harvey
fuente
Es interesante saber que los propios diseñadores de Microsoft no recomiendan el megamodelo compartido; desafortunadamente así es como tienden a usarse Linq to SQL y EF y muchos otros ORM. De todos modos, todavía hay mucha gente promocionando el concepto de modelo canónico y todavía me gustaría saber cómo le va en la práctica frente a la alternativa.
Aaronaught
@Aaronaught: Mira mi edición.
Robert Harvey
Es una buena edición, y para su información lo he votado. Sin embargo, ya soy consciente de muchos de los problemas de incongruencia específicos que surgen cuando se trata de canonizar un modelo; Estoy particularmente interesado en aprender sobre experiencias o datos a largo plazo sobre equipos que han invertido el tiempo para resolver esas incongruencias, a fin de tener un mapeador por punto final (extremo al modelo), en lugar de invertir el tiempo en un extremo separado en su lugar, los mapeadores, y qué enfoques realmente arrojaron las soluciones de menor costo / menor complejidad.
Aaronaught
O para decirlo de manera más sucinta: sé que es mucho trabajo crear y mantener un modelo canónico, lo que quiero saber es cuándo (si alguna vez) se ha observado que los beneficios superan el costo.
Aaronaught