Чи погана практика служб обміну базою даних у SOA?

Нещодавно я читав схеми інтеграції підприємств Хопе та Вулфа, деякі книги Томаса Ерла про SOA та переглядав різні відео та подкасти Уді Дахана та ін. на системах CQRS та керованих подіями

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

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

Я подумав, що це один із способів закріплення меж у SOA - кожен сервіс повинен мати власну базу даних, але потім я прочитав це:

/programming/4019902/soa-joining-data-across-multiple-services

і це говорить про те, що це неправильно робити.

Сегрегація баз даних здається хорошим способом роз’єднання систем, але зараз я трохи заплутаний. Це хороший маршрут? Чи рекомендується вам коли-небудь відокремити базу даних, скажімо, службу SOA, обмежений для DDD контекст, програму тощо?

Розв'язка працює лише в тому випадку, якщо дійсно є розділення. Подумайте, чи є у вас система замовлення:

• Таблиця: КЛІЄНТ
• Таблиця: ЗАМОВИТИ

Якщо це все, що у вас є, немає підстав для їх розв’язки. З іншого боку, якщо у вас це є:

• Таблиця: КЛІЄНТ
• Таблиця: ЗАМОВИТИ
• Таблиця: CUSTOMER_NEWSLETTER

Тоді ви можете стверджувати, що ORDER та CUSTOMER_NEWSLETTER є частиною двох абсолютно окремих модулів (замовлення та маркетинг). Можливо, є сенс перемістити їх у окремі бази даних (по одній для кожної таблиці), і обидва модулі мають доступ до загальної таблиці КЛІЕНТІВ у власній базі даних.

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

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

Де я працюю, у нас є ESBдо яких підключено 6 різних додатків (або я повинен сказати "кінцеві точки"). Ці 6 додатків працюють з 3 різними схемами Oracle на двох екземплярах бази даних. Деякі з цих додатків співіснують в одній схемі не тому, що вони пов'язані між собою, а тому, що інфраструктурою нашої бази даних керує зовнішній провайдер, а отримання нової схеми просто займає назавжди (також ми не маємо доступу до DBA, звичайно) ... Це насправді йде так багато часу, що ми в один момент подумали про повторне використання існуючої схеми "тимчасово", щоб мати можливість продовжувати розробку. Для забезпечення "розділення" даних імена таблиць мають префікс, наприклад "CST_" для клієнта. Крім того, ми повинні працювати зі схемою, яка з якихось поважних причин не може абсолютно змінити ... Дивно, я знаю. Звичайно, як це завжди буває, "тимчасово"

Наші різні програми підключаються до відповідної схеми бази даних та працюють із власними PL / SQL-пакетами, і ми абсолютно забороняємо собі безпосередньо взаємодіяти з таблицями / даними, які знаходяться за межами домену додатка.

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

Ми робимо це для того, щоб мати змогу розділити домен додатка на різні схеми / бази даних, а також щоб служби ESB все ще працювали належним чином, коли це станеться (скоро Різдво, ми перестанемо пальцями)

Тепер це може виглядати дивно і жахливо ззовні, але є причини для цього, і я просто хотів поділитися цим конкретним досвідом, щоб показати вам, що одна чи кілька баз даних не так важливі. Зачекайте, це так! , з багатьох причин (+1 для Скотта Вітлока, див. останній абзац про резервне копіювання та таке, що моє приводить вас у біду) Але не менш важливо, я думаю, щоб ваші служби SOA були правильно розроблені, принаймні, це моя думка, і я Я не DBA. Зрештою, всі ваші бази даних належать до вашого «корпоративного сховища даних», правда?

Нарешті, я не перефразую останній абзац Скотта Вітлока, особливо це

Я б не розділяв таблиці на різні фізичні бази даних тільки через розділення проблем.

насправді супер важливо. Не робіть цього, якщо немає причин.

Я бачив найгірші можливі кошмари в архітектурі програмного забезпечення через інтеграцію даних, і найкраща зброя проти такого типу безладу, з яким я стикався до цих пір ІД-стилів, обмежених стилем DDD. Що не дуже далеко від "SOA зроблено правильно", в певному сенсі.

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

Простіше кажучи: якщо ви шукаєте слабко пов'язані системи, не залишайтеся в поєднанні з даними. Займіться за допомогою укупорених систем, що добре захищені, і добре структурованого каналу зв'язку між ними, який виступає як "lingua franca".

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

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

Будь ласка, дивіться опис Мартіна Фаулера щодо моделі CQRS :

У міру того, як наші потреби стають все більш досконалими, ми неухильно відходимо від [обробки такої інформаційної системи, як сховище даних CRUD] ... Зміна, яку запроваджує CQRS, полягає в тому, щоб розділити цю концептуальну модель на окремі моделі для оновлення та відображення ... Існує місце для значних варіацій тут. Моделі в пам'яті можуть мати спільну базу даних, і в цьому випадку база даних виконує функції зв'язку між двома моделями. Однак вони також можуть використовувати окремі бази даних , ефективно роблячи базу даних сторони запитів за допомогою бази даних ReportingData в реальному часі. У цьому випадку повинен бути механізм зв'язку між двома моделями або їх базами даних.

І архітектурні принципи NServiceBus :

Розділення запитів команд

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

І розділення відповідальності за команду та запити (CQRS)

Сегрегація відповідальності команд та запитів

Більшість програм читає дані частіше, ніж вони записують дані. Виходячи з цього твердження, було б корисно прийняти рішення, де легко можна додати більше баз даних для читання, правда? Що робити, якщо ми створили базу даних, призначену саме для читання? Навіть краще; що робити, якщо ми розробляємо базу даних таким чином, щоб швидше її читати? Якщо ви розробляєте свої програми на основі шаблонів, описаних в архітектурі CQRS, у вас з'явиться рішення, яке масштабується і швидко читає дані.