OSGi и модульность постоянства: влияние отношений

Question

Большинство вопросов, связанных с заголовком этого поста, касаются запуска Hibernate или какого-либо другого уровня доступа в контейнере OSGi. Или они спрашивают, чтобы источник данных работал в контейнере OSGi.

Мои вопросы касаются влияния модульности OSGi на структуру самой базы данных. В частности:

1. Как сделать структуру самой базы данных модульной, чтобы когда мы загружаем модуль - скажем, Contact Management - схема обновлены, чтобы включить таблицы, специально связанные с этим модулем?
2. Как влияет вышеизложенный подход на отношения?

Я думаю, что второй вопрос более интересен. Допустим, что Contact Management и Project Management - это два разных модуля OSGi. Каждый из них будет иметь свой собственный набор таблиц в схеме. Но что, если на уровне базы данных нам нужно сформировать межмодульные отношения между двумя или более таблицами? Может быть, мы хотим увидеть список проектов, над которыми работает или работал определенный контакт.

Кажется, любое решение ведет к тому, что различные модули должны слишком много знать друг о друге. Мы могли бы написать в спецификации Project Management, что этот модуль ожидает источник контактов, а затем абстрагировать такое ожидание с помощью сервисов, интерфейсов, pub-sub и т. Д. Это похоже на большую работу, чтобы избежать жесткой связи между базовые таблицы двух модулей.

Какой смысл быть модульным вверху и посередине, если нам, возможно, потребуется разбить эту модульность с помощью связей между таблицами внизу? Являются ли денормализация и сервисная шина действительно полезным решением?

Есть мысли?

Спасибо.

Answer 1

После 5 лет JPA я решил покинуть его, и после нескольких месяцев исследований я нашел комбинацию Querydsl + Liquibase лучшей.

Я много работал над разработкой вспомогательных компонентов OSGi и подключаемого модуля maven.Функциональность maven-plugin (генерация кода) может быть легко интегрирована в другие инструменты сборки, поскольку плагин maven является лишь оболочкой вокруг автономной библиотеки.

Подробную статью о решении можно найти здесь: http://bzsoldos.wordpress.com/2014/06/18/modularized-persistence/

Answer 2

Что касается первого вопроса, можно использовать LiquiBase . Вы можете обновлять и откатывать наборы изменений при активации и деактивации пакета.

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

Answer 3

Возможно, я неправильно понял вопрос, но, по моему мнению, модульность OSGI абсолютно не влияет на структуру базы данных.Это уровень хранения данных, конечно, он может быть модульным, но по своим собственным причинам - производительность, объемы данных, нагрузка и т. Д., А также с собственными решениями - кластерами, olap, разбиением и репликацией.

Есливам нужна целостность данных между cm и pm, это должно быть обеспечено средствами, изначально разработанными для такого рода задач - RDBMS.Если вам нужна модульность программного обеспечения - вы выбираете решение OSGI, и ваши модули взаимодействуют на гораздо более высоком логическом / бизнес-уровне.Они могут совершенно не знать, как обеспечивается постоянство - обычный текстовый файл или кластер Oracle RAC из 100 узлов.

Answer 4

В такой ситуации важно оценить, насколько независимы эти модули / контексты.В терминах DDD эти два кажутся независимыми ограниченными контекстами, поэтому контакт в модуле pm - это отдельный объект (а также другой класс), чем контакт в модуле cm.Если вы сохраните это различие, то у вас возникнет некоторая денормализация в отношении объекта контакта (например, при добавлении его в проект вы скопируете идентификатор и имя контакта, последующие изменения контакта в модуле cm потребуют некоторого pubsub для обеспечения согласованности),каждый модуль будет очень независимым.Я бы оставил интерфейс в виде отдельного модуля, в зависимости от того и другого и предоставляя необходимый клей (т.е. передавая между ними идентификаторы и требуемую информацию).