Чи підтверджують поточні докази прийняття контекстуальних над канонічними моделями даних?

"Канонічна" ідея є всеосяжною у програмному забезпеченні; такі моделі , як Canonical Model , Canonical Schema , Canonical Data Model тощо, здаються, знову і знову з'являються у розвитку.

Як і багато розробників, я часто некритично дотримувався загальноприйнятої думки про те, що вам потрібна канонічна модель, інакше ви зіткнетеся з комбінаторним вибухом картографів та перекладачів. Або, принаймні, я раніше це робив до пари років тому, коли я вперше прочитав дещо сумнозвісний EF Vote of Not Confidence :

Гіпотези, які колись підтримували здійснення канонічних моделей даних, не включали і не могли включати чинників, які були б виявлені, як тільки ідея була втілена в життя. Через роки спроб та помилок ми виявили, що використання окремих моделей для кожного окремого контексту, в якому може використовуватися канонічна модель даних, є найменш складним підходом, є найменш затратним підходом, і той, що призводить до більшої ремонтопридатності та розширюваності додатків і кінцевих точок, що використовують контекстні моделі, і це підхід, який не заохочує ентропію програмного забезпечення, яку роблять канонічні моделі.

У рефераті немає жодних доказів, які б підтверджували його твердження, але все-таки змусило мене поставити під сумнів підхід щодо МЧР досить довго, щоб спробувати альтернативу, і отримане програмне забезпечення не вибухнуло ні в прямому, ні в переносному значенні. Але це не означає, що дуже багато ізольовано; Мені могло просто пощастило.

Тож мені цікаво, чи було проведено якесь серйозне дослідження практичних, довготермінових наслідків наявності канонічної моделі порівняно з контекстними моделями в програмній системі чи архітектурі?

Або, якщо про це ще рано запитувати, чи не писали будь-які розробники / архітектори про особистий досвід переходу з CDM на незалежні контекстуальні моделі, або навпаки, і які практичні ефекти мали такі речі, як продуктивність, складність чи надійність?

А як щодо відмінностей на різних рівнях, тобто використання однієї і тієї ж моделі в одній програмі порівняно з її використанням у системі програм або цілому підприємстві?

(Будь-які факти, будь ласка; історії війни вітаються, але не догадуються.)

У відповідь на статтю " Голосування ЄФ" Без довіри " Тім Маллаліє пише:

Ми не рекомендуємо людям повертатися до днів, коли ми благословляли використання XSD для "канонічних схем". Я не вірю, що люди думають, що це можна відстежити. Однак ми вважаємо, що бажано мати єдину мета-модель (EDM, якщо ви хочете), за допомогою якої ви можете описати багато моделей домену, і, маючи одну граматику, ми можемо надати набір загальних служб для будь-яких задана модель домену.

Наприклад, розглянемо додаток, який потрібно написати проти бази даних з 600 таблицями. Чи вважаю я, що ця програма повинна мати єдину модель із 600 типами суб'єктів? Ні ... Крім того, чи я вважаю, що будь-яка дана організація домену (скажімо, Клієнт) має лише одну форму в цьому додатку і що ця форма повинна бути канонічною формою для всього Підприємства?… Хек ні.

Стаття у Вікіпедії для Canonical Model посилається на такі речі, як Enterprise Service Bus , зорієнтована на сервіс архітектура та CORBA , такі речі, які, здається, про них вже майже не розмовляють. Усі вони були вирішеними для вирішення проблем, пов'язаних із розповсюдженням даних та комунікацій, - Єдине кільце для всіх. ^TM Чи їм це вдалося? Або вони розвалилися під власною вагою?

Ви попросили особистого досвіду, тож я дам вам один. В аерокосмічній промисловості ми багато використовуємо телеметрію. Одне з викликів перед телеметричними системами - це пошук способу для різних тестових діапазонів для змістовного передачі даних тестів між собою. Ця проблема здається досить простою, поки ви не спробуєте визначити словник даних із загальних термінів.

Що означає "висота"? Це висота над землею, чи це висота над рівнем моря? Що робити, якщо ви говорите про підводний човен? Тоді його глибина, а не висота. Для армії слово "передача" має інше значення, коли ви маєте на увазі радіолокаційну тарілку, ніж це стосується наземного транспортного засобу. Поверхня крила, яка змушує літак перекочуватися, на одних літаках називається «ейрон», а в інших - «елевоном».

Це лише натяк на гору проблем, які випливають. Хоча існують стандарти для передачі даних, кожен тестовий діапазон різний і має різні потреби, цілі та пріоритети. Стандарти можуть відрізнятися навіть у різних проектах одного і того ж діапазону. З цієї причини тестові діапазони розуміють, що рішення не прийде заміною всього єдиною, монолітною системою, а узгодженням простих протоколів зв'язку та наданням способів перекладу з лексики одного діапазону в інший.

Проблеми, з якими стикаються великі компанії, схожі. Microsoft схильна мислити в монолітному плані, але це тому, що їхня компанія, як правило, монолітна. Як тільки вам потрібно буде спілкуватися між різними компаніями з абсолютно різними культурами та способами ведення бізнесу (або навіть між різними відділами в одній компанії), Єдине кільце для правила всіх. ^ТМ відразу починає руйнуватися.