Le prove attuali supportano l'adozione di modelli contestuali rispetto a modelli canonici?

L'idea "canonica" è pervasiva nel software; modelli come Modello canonico , Schema canonico , Modello dati canonico e così via, sembrano emergere ancora e ancora in fase di sviluppo.

Come molti sviluppatori, ho spesso seguito, acriticamente, la saggezza convenzionale secondo cui hai bisogno di un modello canonico, altrimenti dovrai affrontare un'esplosione combinatoria di mappatori e traduttori. O almeno, ho usato per fare che fino a un paio di anni fa, quando ho letto il po-infame EF voto di sfiducia :

Le ipotesi che un tempo sostenevano il perseguimento di modelli di dati canonici non erano e non potevano includere fattori che sarebbero stati scoperti una volta che l'idea sarebbe stata messa in pratica. Abbiamo scoperto, attraverso anni di tentativi ed errori, che l'utilizzo di modelli separati per ogni singolo contesto in cui un modello di dati canonico potrebbe essere utilizzato è l'approccio meno complesso, è l'approccio meno costoso e quello che porta a una maggiore manutenibilità ed estensibilità delle applicazioni e degli endpoint che utilizzano modelli contestuali, ed è un approccio che non incoraggia l'entropia del software che fanno i modelli canonici.

Il saggio non presenta prove di alcun tipo a supporto delle sue affermazioni, ma mi ha fatto mettere in dubbio l'approccio CDM abbastanza a lungo per provare l'alternativa e il software risultante non è esploso, letteralmente o figurativamente. Ma ciò non significa molto in isolamento; Avrei potuto essere solo fortunato.

Quindi mi chiedo, sono state fatte ricerche serie sugli effetti pratici a lungo termine dell'avere un modello canonico rispetto ai modelli contestuali in un sistema software o in un'architettura?

Oppure, se è troppo presto per chiederlo, allora alcuni sviluppatori / architetti hanno scritto di esperienze personali che passano da un CDM a modelli contestuali indipendenti, o viceversa, e quali sono stati gli effetti pratici su cose come produttività, complessità o affidabilità?

Che dire delle differenze a diversi livelli, ovvero utilizzando lo stesso modello in una singola applicazione anziché utilizzarlo in un sistema di applicazioni o un'intera impresa?

(Solo fatti, per favore; le storie di guerra sono benvenute ma nessuna speculazione.)

In risposta all'articolo EF Vote of No Confidence , Tim Mallalieu scrive:

Non stiamo raccomandando che la gente ritorni ai giorni in cui evangelizzavamo l'uso dell'XSD per "schemi canonici". Non credo che la gente pensi che questo sia trattabile. Ciò in cui crediamo, tuttavia, è che sia desiderabile avere un singolo meta-modello (EDM se vuoi) con il quale puoi descrivere molti modelli di dominio e che con un'unica grammatica possiamo fornire un insieme di servizi comuni su qualsiasi dato modello di dominio.

Ad esempio, considerare un'applicazione che deve essere scritta su un database con 600 tabelle. Credo che questa app dovrebbe avere un singolo modello con 600 tipi di entità al suo interno? No ... Inoltre, credo che una determinata entità di dominio (ad esempio il Cliente) abbia una sola forma in quell'app e che questa forma debba essere la forma canonica per l'intera Azienda? ... Diamine no.

L'articolo di Wikipedia per il modello canonico fa riferimento a cose come Enterprise Service Bus , Service-Oriented Architecture e CORBA , cose che sembrano quasi non essere più menzionate. Furono tutti posti come la soluzione alla proliferazione dei dati e alle sfide di comunicazione dell'impresa, il One Ring to Rule Them All. ^TM Ci sono riusciti? O sono crollati sotto il loro stesso peso?

Hai chiesto esperienze personali, quindi te ne darò una. Nel settore aerospaziale utilizziamo molto la telemetria. Una delle sfide con i sistemi di telemetria è trovare un modo per diversi intervalli di test di comunicare i dati dei test in modo significativo. Questo problema sembra abbastanza semplice, finché non si tenta di definire un dizionario di dati di termini comuni.

Cosa significa "altitudine"? È l'altezza dal suolo o è l'altezza dal livello del mare? E se stai parlando di un sottomarino? Quindi la sua profondità, non l'altitudine. Per l'esercito, la parola "trasmissione" ha un significato diverso quando ti riferisci a un'antenna radar rispetto a un veicolo terrestre. La superficie dell'ala che fa rotolare un aereo è chiamata "alettone" su alcuni piani e "elevone" su altri.

Questo è solo un suggerimento per la montagna di problemi che seguono. Sebbene esistano standard per la comunicazione dei dati, ogni intervallo di test è diverso e ha esigenze, obiettivi e priorità diversi. Gli standard possono differire anche tra progetti diversi nella stessa gamma. Per questo motivo, i range di test comprendono che la soluzione non arriverà sostituendo tutto con un unico sistema monolitico, ma concordando semplici protocolli di comunicazione e fornendo modi per tradurre dal vocabolario di un range a un altro.

I problemi che devono affrontare le grandi aziende sono simili. Microsoft tende a pensare in termini monolitici, ma ciò è dovuto al fatto che la sua società è, in linea generale, monolitica. Non appena è necessario comunicare tra aziende diverse con culture e modalità di business molto diverse (o anche tra dipartimenti diversi nella stessa azienda), One Ring to Rule Them All. ^TM inizia immediatamente a guastarsi.