Является ли плохой практикой для служб совместное использование базы данных в SOA?

Недавно я читал «Образцы корпоративной интеграции» Хопе и Вульфа, некоторые из книг Томаса Эрла по SOA, а также смотрел различные видео и подкасты Уди Дахана и других. в CQRS и управляемых событиями системах.

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

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

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

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

и это говорит о том, что это неправильно.

Разделение баз данных кажется хорошим способом разделения систем, но теперь я немного запутался. Это хороший маршрут? Рекомендовано ли вам когда-либо разделять базу данных, например, на службу SOA, контекст с ограничением DDD, приложение и т. Д.?

Разделение работает, только если действительно существует разделение. Подумайте, есть ли у вас система заказа:

• Таблица: ЗАКАЗЧИК
• Таблица: ЗАКАЗАТЬ

Если это все, что у вас есть, нет причин разъединять их. С другой стороны, если у вас есть это:

• Таблица: ЗАКАЗЧИК
• Таблица: ЗАКАЗАТЬ
• Таблица: CUSTOMER_NEWSLETTER

Тогда вы можете утверждать, что ORDER и CUSTOMER_NEWSLETTER являются частью двух совершенно отдельных модулей (заказ и маркетинг). Возможно, имеет смысл перенести их в отдельные базы данных (по одной для каждой таблицы), и оба модуля имеют общий доступ к общей таблице CUSTOMER в своей собственной базе данных.

Этим вы упрощаете каждый модуль, но усложняете уровень данных. Поскольку ваше приложение становится все больше и больше, я вижу преимущество в разделении. Будет все больше и больше «островков данных», которые действительно не имеют никакого отношения друг к другу. Тем не менее, всегда будут некоторые данные, которые пересекают все модули.

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

Где я работаю, у нас есть ESBк которому подключено 6 различных приложений (или, если можно так выразиться, «конечные точки»). Эти 6 приложений работают с 3 различными схемами Oracle на 2 экземплярах базы данных. Некоторые из этих приложений сосуществуют в одной и той же схеме не потому, что они связаны, а потому, что нашей инфраструктурой базы данных управляет внешний поставщик, и получение новой схемы просто занимает вечность (к тому же, конечно, у нас нет доступа к БД) ... на самом деле это занимает так много времени, что в какой-то момент мы подумали о временном использовании существующей схемы, чтобы иметь возможность продолжить разработку. Чтобы обеспечить «разделение» данных, имена таблиц имеют префикс, например «CST_» для клиента. Кроме того, мы должны работать со схемой, которая по некоторым уважительным причинам не может быть абсолютно изменена ... Странно, я знаю. Конечно, как это всегда бывает, «временно»

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

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

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

Сейчас это может выглядеть странно и ужасно со стороны, но для этого есть причины, и я просто хотел поделиться этим конкретным опытом, чтобы показать вам, что одна или несколько баз данных не так важны. Подождите, это так! по многим причинам (+1 для Скотта Уитлока, см. последний абзац о резервном копировании и о том, что mya может привести к неприятностям) Но не менее важно, чтобы я думал, что ваши сервисы SOA должным образом спроектированы, по крайней мере, это мое мнение Я не администратор базы данных. В конечном счете, все ваши базы данных принадлежат вашему «хранилищу данных предприятия», верно?

Наконец, я не буду перефразировать последний абзац Скотта Уитлока, особенно этот

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

это действительно супер важно. Не делай этого, если нет причин.

Я видел наихудшие из возможных кошмаров в архитектуре программного обеспечения из-за интеграции данных и лучшее оружие против такого типа беспорядка, с которым я столкнулся до сих пор в контексте ограниченного контекста в стиле DDD. Что не очень далеко от "SOA сделано правильно", в определенном смысле.

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

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

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

Если все сделано правильно, разделение бизнес-задач на разные базы данных (или, по крайней мере, разные схемы) является достоинством .

Пожалуйста, смотрите описание Мартина Фаулера паттерна CQRS :

По мере того, как наши потребности становятся все более сложными, мы постепенно отходим от [обработки информационной системы, такой как хранилище данных CRUD] ... Изменение, которое вводит CQRS, заключается в разделении этой концептуальной модели на отдельные модели для обновления и отображения ... Есть место для значительных изменений Вот. Модели в памяти могут совместно использовать одну и ту же базу данных, и в этом случае база данных действует как связь между двумя моделями. Однако они также могут использовать отдельные базы данных , эффективно создавая базу данных на стороне запроса в режиме реального времени ReportingDatabase. В этом случае должен быть какой-то механизм связи между двумя моделями или их базами данных.

И NServiceBus Архитектурные Принципы :

Разделение командного запроса

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

И разделение ответственности команд и запросов (CQRS)

Разделение ответственности команд и запросов

Большинство приложений читает данные чаще, чем пишут данные. Основываясь на этом утверждении, было бы неплохо найти решение, в котором легко можно было бы добавить больше баз данных для чтения, верно? Так что, если мы настроим базу данных, предназначенную только для чтения? Даже лучше; Что если мы спроектируем базу данных таким образом, чтобы она быстрее читалась из нее? Если вы разрабатываете свои приложения на основе шаблонов, описанных в архитектуре CQRS, у вас будет решение, которое можно масштабировать и быстро читать данные.