Рекомендации по проектированию слабосвязанных целостных систем?

Question

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

Например, давайте сделаем еще один шаг к примеру со старым зоомагазином и создадим франшизу для зоомагазина. У каждого зоомагазина есть собственный веб-сайт, на котором указаны их контактная информация, рекламные акции и текущий ассортимент.

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

Таким образом, в этом случае списки акций «принадлежат» магазинам, а контактная информация частично «принадлежит» обоим организациям, а информация о продвижении «принадлежит» HQ. По произвольным причинам все эти данные не могут храниться в одном месте.

Существуют ли передовые практики или общие стратегии для преодоления подобной ситуации?

Answer 1

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

Другой пример, который мне нравится использовать, это Продукты.

Продукт может играть множество разных ролей. Он связан с OrderItem, который связан с Order, который связан с Customer.

Предоставлено Продавцом.

Это в каталоге, может быть, по разделам и страницам.

Это ответственность Покупателя, доступность от нескольких поставщиков.

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

В сторону: есть еще одно ORM (моделирование ролей объектов, см. VisioModeler, InfoModeler и т. Д.), Которое довольно полезно (на ИМХО) рассматривает вопрос с реляционной стороны.

Когда вы изолируете себя от реляционной базы данных (используя генераторы CRUD, ActiveRecords и т. Д.), Вы скрываете этот важный аспект. (Я думаю, что у LINQ есть та же проблема, что и при введении фундаментальных проблем связи, но я еще не совсем решил ее.)

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

Answer 2

Похоже, SOA может помочь в этом случае. Я конкретно имею в виду SOA бизнес-уровня, как описано, например, Билл Пул и Уди Дахан с асинхронной реализацией pub-sub на основе событий.

Вы описали несколько бизнес-функций с отдельными владельцами: франчайзинг и продажи. Вы хотите добиться слабой связи между ними.

В SOA вы определяете сервис франчайзинга и несколько экземпляров сервисов продаж, по одному для каждого магазина. Магазины изначально очень похожи, но могут развиваться отдельно.

Затем вы определяете деловые события, представляющие взаимный интерес, которые происходят в этих службах. Сервис франчайзинга может публиковать событие NewPromotion, на которое подписываются все службы продаж. Это сообщение содержит все подробности о продвижении, и потребители выбирают то, что им нужно. В свою очередь, служба продаж публикует событие ContactDetailsChanged, которое будет использовано Franchising.

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

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

На стороне реализации вам нужна какая-то служебная шина между службами с поддержкой надежного обмена сообщениями через ненадежный Интернет, например, NServiceBus . Нет необходимости в WebServices (tm).

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

Надеюсь, это поможет:)

Answer 3

Насколько я понимаю, проблема такого рода чаще всего решается с использованием метода, называемого «объединение данных» - независимые объекты функционируют независимо, но существует сущность, похожая на зонтик, которая дает возможность рассматривать систему в целом .

Вот статья, которая может быть полезна: http://www.soamag.com/I22/0908-1.asp

При планировании своей архитектуры помните, что происходит, когда один из участников недоступен. Например, я бы порекомендовал реплицировать информацию о продвижении во все магазины, либо как пакетный процесс, либо при изменении справочных данных. Таким образом, если сеть выходит из строя, отдельные магазины по-прежнему имеют информацию о продвижении и могут функционировать.

Answer 4

Я в основном согласен с предложенным выше решением (с использованием SOA). ESB может быть хорошим подходом в зависимости от сложности приложения. Но я думаю, что ESB занимает много места и приносит ненужную сложность для большинства реальных приложений.

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

Предполагается, что средне-крупномасштабное n-уровневое приложение на основе Java предлагает следующие рекомендации для среднего и EIS-уровней:

1. Отделяйте каждую из реализаций подсистемы и раскрывайте ее функциональные возможности через интерфейс службы и скрывайте реализации от непосредственного использования или ссылки.

2. Создайте один файл JAR (или EAR) для каждой из подсистем и определите зависимости времени выполнения и времени компиляции между указанными выше подсистемами / JAR.

3. Потратьте много времени на определение правильной гранулярности методов интерфейса службы и зависимостей подсистемы.

4. Во время этой попытки попытайтесь определить уровень DAO (при условии, что задействована БД) для каждого из модулей и отделить таблицы базы данных для каждой из подсистем.

Для веб-уровня попробуйте сделать то же, что и выше, разделив уровень представления по подсистемам. Создайте один файл WAR для каждой из подсистем. Попытайтесь поместить WAR уровня представления в соответствующий файл EAR, определенный выше, если необходимо.

Хорошей проверкой этой вышеупомянутой архитектуры является ее развертывание в OSGi с использованием каждой из служб в качестве службы OSGi (после создания соответствующих файлов манифеста).

Имейте в виду, что основанная на событиях / асинхронная связь может быть установлена ​​также между любой из этих подсистем, если это необходимо.

Это дает возможность разделить подсистемы и развернуть их на разных фермах серверов для улучшения возможностей масштабирования.

Удачи ..!