Мікросервіси та канонічна модель

Коли я читав про мікросервіси на цьому сайті , я натрапив на нижченаведене твердження. Що означає канонічна схема? Це не те саме, що і доменна модель?

Шаблон архітектури мікросервісів також відкидає інші частини SOA, наприклад концепцію канонічної схеми.

— Пунтер Вікі
джерело

Чи трапляється вам знати джерело цього твердження? (для цілей зв’язку)

— Джек

Звичайно, Джек, саме тут - nginx.com/blog/introduction-to-microservices/…

— Punter Vicky

Я вважаю, що ця стаття у Вікіпедії - це те, що ви шукаєте. Однак я не вважаю статтю легко зрозумілою.

— Арсеній Муренко

Дякую @ArseniMourzenko Я вірю, що навіть в архітектурі мікросервісів, запит і відповідь повинні відповідати деякій моделі даних. Ще не в змозі зрозуміти, чому її називають відхиленою архітектурою мікросервісу.

— Punter Vicky

Деяка модель даних так, але мені здається, що в статті йдеться про "спільні" або "загальні" моделі даних між двома або більше службами. Схема Canonical - це схема, призначена для врятування служб від перетворень даних під час виконання. Загальна "мова" між службами. Так виглядає, що стаття наголошує на повній незалежності країн-членів від "екосистеми", де вона живе. Візьмемо для прикладу згадку про ESB. ESB зазвичай вимагає корпоративну модель даних (повідомлення), яка буде загальною для всіх в шині. MS відхиляє приєднання до будь-якого зовнішнього звуження системи.

— Лаїв

Відповіді:

Вибачте заздалегідь, покладаючись на коментар @ArseniMourzenko, але як тільки я почав читати Вікіпедію, я одразу зрозумів, що означає канонічна схема .

Ось коментар ОП, який зосереджений на реальному сумніві

Я вірю, що навіть в архітектурі мікросервісів, запит і відповідь повинні відповідати деякій моделі даних.

Деяка модель даних так, але здається, що в статті йдеться про "спільну" або "загальну" моделі даних між двома або більше службами.

Canonical схема являє собою модель призначена для збереження послуг від в перетвореннях даних у час виконання. Це також позбавляє вас від дублювання коду. Але ви приєднуєте свою послугу і до зовнішньої моделі даних. (Дивіться схеми на сторінці Вікіпедії, пов'язаної вище)

Це свого роду загальна "мова" між службами.

Так виглядає, що стаття наголошує на повній незалежності країн-членів від "екосистеми", де вона живе.

Візьмемо для прикладу згадку про ESB.

Вони також дуже уникають використання ESB, а натомість реалізують ESB-подібну функціональність у самих мікросервісах.

ESB зазвичай вимагає модель даних (повідомлень) для підприємств, яка буде загальною для всіх, приєднаних до шини.

Отже, повертаючись до статті, видається, що автор вказує на те, що MS відмовляється бути приєднаною до будь-якої зовнішньої системи (та їх обмежень) .

— Лаїв
джерело

Дякую @Laiv Я вручу нагороду за 9 годин - так мене обмежує :)

— Punter Vicky

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

Мікросервіси повинні бути тісно узгоджені з обмеженими контекстами, що стосується дизайну, керованого доменом.

— pnschofield
джерело

If you find that you have microservices making synchronous calls. Не обов'язково асинхронні дзвінки. Це може статися і з асинхронними повідомленнями ESB. Я думаю, що це зосереджено на тому, щоб бути пов'язаним із спільними схемами чи договорами даних. Я припускаю, що в архітектурі MS слід уникати будь-яких комунікацій p2p між сервісами. Спілкування має відбуватися через додатки замість будь-якого внутрішнього (внутрішнього рівня обслуговування) або зовнішнього (ESB, черги тощо)

— Laiv