As evidências atuais apóiam a adoção de modelos de dados contextuais sobre modelos canônicos?

A idéia "canônica" é difundida em software; padrões como Modelo Canônico , Esquema Canônico , Modelo de Dados Canônico e assim por diante, parecem surgir repetidamente em desenvolvimento.

Como muitos desenvolvedores, muitas vezes segui, sem crítica, a sabedoria convencional de que você precisa de um modelo canônico; caso contrário, você enfrentará uma explosão combinatória de mapeadores e tradutores. Ou pelo menos, eu costumava fazer isso até um par de anos atrás, quando li pela primeira vez a um pouco infame EF voto de confiança :

As hipóteses que antes apoiavam a busca de modelos de dados canônicos não incluíam nem poderiam incluir fatores que seriam descobertos quando a idéia fosse posta em prática. Descobrimos, através de anos de tentativa e erro, que o uso de modelos separados para cada contexto individual em que um modelo de dados canônicos pode ser usado é a abordagem menos complexa, é a abordagem menos onerosa e a que leva a maior capacidade de manutenção e extensibilidade dos aplicativos e pontos de extremidade usando modelos contextuais, e é uma abordagem que não incentiva a entropia de software que os modelos canônicos fazem.

O ensaio não apresenta nenhuma evidência de qualquer tipo para apoiar suas afirmações, mas me fez questionar a abordagem do MDL por tempo suficiente para tentar a alternativa, e o software resultante não explodiu, literal ou figurativamente. Mas isso não significa muito isolado; Eu poderia ter tido sorte.

Então, eu estou me perguntando, alguma pesquisa séria foi feita sobre os efeitos práticos e de longo prazo de ter um modelo canônico versus modelos contextuais em um sistema ou arquitetura de software?

Ou, se for muito cedo para perguntar isso, algum desenvolvedor / arquiteto escreveu sobre experiências pessoais mudando de um CDM para modelos contextuais independentes, ou vice-versa, e quais foram os efeitos práticos em coisas como produtividade, complexidade ou confiabilidade?

E as diferenças em diferentes níveis, ou seja, usar o mesmo modelo em um único aplicativo vs. usá-lo em um sistema de aplicativos ou em uma empresa inteira?

(Apenas fatos, por favor; histórias de guerra são bem-vindas, mas não há especulação.)

Em resposta ao artigo EF Vote of No Confidence , Tim Mallalieu escreve:

Não estamos recomendando que as pessoas voltem aos dias em que estávamos evangelizando o uso de XSD para "esquemas canônicos". Não acredito que as pessoas pensem que isso é tratável. No entanto, acreditamos que é desejável ter um único metamodelo (EDM, se desejar) com o qual você pode descrever muitos modelos de domínio e que, com uma gramática única, podemos fornecer um conjunto de serviços comuns em qualquer determinado modelo de domínio.

Por exemplo, considere um aplicativo que deve ser gravado em um banco de dados com 600 tabelas. Eu acredito que este aplicativo deve ter um modelo único com 600 tipos de entidade? Não ... Além disso, acredito que qualquer entidade de domínio (digamos, Cliente) tem apenas uma forma nesse aplicativo e que essa forma deve ser a forma canônica para toda a empresa? ... Caramba, não.

O artigo da Wikipedia para Canonical Model faz referência a coisas como Enterprise Service Bus , Service-Oriented Architecture e CORBA , coisas que parecem dificilmente serem discutidas. Todos foram colocados como a solução para os desafios de proliferação e comunicação de dados da empresa, o único anel para governar todos eles. ^TM eles conseguiram? Ou eles entraram em colapso com seu próprio peso?

Você pediu experiências pessoais, então eu lhe darei uma. Na indústria aeroespacial, usamos muito a telemetria. Um dos desafios dos sistemas de telemetria é encontrar uma maneira de diferentes faixas de teste comunicarem dados de teste de maneira significativa. Esse problema parece bastante simples, até você tentar definir um dicionário de dados com termos comuns.

O que significa "altitude"? É a altura acima do solo ou é a altura acima do nível do mar? E se você estiver falando de um submarino? Então sua profundidade, não altitude. Para o Exército, a palavra "transmissão" tem um significado diferente quando você está se referindo a uma antena parabólica do que a um veículo terrestre. A superfície da asa que faz a aeronave rolar é chamada de "aileron" em alguns aviões e de "onze" em outros.

Essa é apenas uma dica da montanha de problemas que se seguem. Embora existam padrões para a comunicação de dados, cada faixa de teste é diferente e possui diferentes necessidades, objetivos e prioridades. Os padrões podem diferir mesmo entre projetos diferentes no mesmo intervalo. Por esse motivo, os intervalos de teste entendem que a solução não virá substituindo tudo por um único sistema monolítico, mas concordando com protocolos de comunicação simples e fornecendo maneiras de traduzir o vocabulário de um intervalo para outro.

Os problemas que as grandes empresas enfrentam são semelhantes. A Microsoft tende a pensar em termos monolíticos, mas isso ocorre porque sua empresa é, em geral, monolítica. Assim que você precisar se comunicar entre empresas diferentes, com culturas e maneiras muito diferentes de fazer negócios (ou mesmo entre departamentos diferentes na mesma empresa), o único anel para governar todos eles. ^{A TM} imediatamente começa a quebrar.