Поддерживает ли текущее доказательство принятие контекстных по сравнению с каноническими моделями данных?

«Каноническая» идея широко распространена в программном обеспечении; паттерны, такие как Canonical Model , Canonical Schema , Canonical Data Model и т. д., как представляется, снова и снова появляются в процессе разработки.

Как и многие разработчики, я часто некритически следовал общепринятому мнению, что вам нужна каноническая модель, иначе вы столкнетесь с комбинаторным взрывом картостроителей и переводчиков. Или , по крайней мере, я использовал, чтобы сделать это , пока пару лет назад , когда я впервые прочитал несколько-позорный EF вотум недоверия :

Гипотезы, которые когда-то поддерживали стремление к каноническим моделям данных, не включали и не могли включать факторы, которые будут обнаружены, как только идея будет реализована на практике. В течение многих лет проб и ошибок мы обнаружили, что использование отдельных моделей для каждого отдельного контекста, в котором может использоваться каноническая модель данных, является наименее сложным подходом, наименее затратным подходом, и тот, который приводит к большей ремонтопригодности и расширяемости приложений и конечных точек, использующих контекстные модели, и этот подход не поощряет энтропию программного обеспечения, как это делают канонические модели.

Эссе не содержит каких-либо доказательств в поддержку своих утверждений, но заставило меня усомниться в подходе CDM достаточно долго, чтобы попробовать альтернативу, и получающееся в результате программное обеспечение не взорвалось ни в прямом, ни в переносном смысле. Но это не значит много в изоляции; Мне бы просто повезло.

Поэтому мне интересно, проводились ли какие-либо серьезные исследования практических, долгосрочных последствий наличия канонической модели в сравнении с контекстными моделями в программной системе или архитектуре?

Или, если еще слишком рано об этом спрашивать, то написали ли разработчики / архитекторы о личном опыте перехода с CDM на независимые контекстные модели или наоборот, и как это повлияло на такие вещи, как производительность, сложность или надежность?

Как насчет различий на разных уровнях, т. Е. Использование одной и той же модели в одном приложении или ее использование в системе приложений или на всем предприятии?

(Только факты, пожалуйста; истории войны приветствуются, но не спекуляции.)

В ответ на статью EF «Голос за недоверие» Тим Маллиу пишет:

Мы не рекомендуем возвращаться к тем дням, когда мы проповедовали использование XSD для «канонических схем». Я не верю, что люди думают, что это поддается лечению. Однако мы верим, что желательно иметь единую метамодель (EDM, если хотите), с помощью которой вы можете описать множество моделей предметной области, и что, имея единую грамматику, мы можем предоставить набор общих служб для любого данная модель предметной области.

Например, рассмотрим приложение, которое должно быть записано в базу данных с 600 таблицами. Верю ли я, что в этом приложении должна быть одна модель с 600 типами объектов? Нет ... Кроме того, считаю ли я, что какой-либо конкретный объект домена (скажем, Клиент) имеет только одну форму в этом приложении и что эта форма должна быть канонической формой для всего Предприятия? ... Черт, нет.

В статье Wikipedia для Canonical Model упоминаются такие вещи, как Enterprise Service Bus , Service-Oriented Architecture и CORBA , вещи, о которых кажется, что о них больше не говорят. Все они были поставлены как решение проблем распространения данных и коммуникаций на предприятии, « Единый звонок, чтобы управлять ими всеми». ^Т.М. Им это удалось? Или они развалились под собственным весом?

Вы просили о личном опыте, поэтому я дам вам один. В аэрокосмической промышленности мы часто используем телеметрию. Одна из проблем, связанных с системами телеметрии, заключается в том, чтобы найти разные диапазоны испытаний для осмысленного обмена данными испытаний. Эта проблема кажется достаточно простой, пока вы не попытаетесь определить словарь данных общих терминов.

Что означает «высота»? Это высота над землей или высота над уровнем моря? Что если вы говорите о подводной лодке? Тогда его глубина, а не высота. Для армии слово «передача» имеет другое значение, когда вы имеете в виду радиолокационную антенну, а не наземное транспортное средство. Поверхность крыла, которая вызывает крен самолета, на одних самолетах называется элероном, а на других - элевоном.

Это только намек на гору проблем, которые следуют. Хотя существуют стандарты для передачи данных, каждый диапазон испытаний различен и имеет разные потребности, цели и приоритеты. Стандарты могут отличаться даже между различными проектами в одном диапазоне. По этой причине тестовые диапазоны понимают, что решение придет не путем замены всего на одну монолитную систему, а путем согласования простых протоколов связи и предоставления способов перевода из словаря одного диапазона в другой.

Проблемы, с которыми сталкиваются крупные компании, похожи. Microsoft склонна мыслить монолитно, но это потому, что их компания в целом монолитна. Как только вам нужно будет общаться между разными компаниями с совершенно разными культурами и способами ведения бизнеса (или даже между разрозненными отделами в одной и той же компании), « Одно кольцо - управлять ими всеми». ^ТМ сразу начинает ломаться.