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

Question

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

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

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

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

Есть ли какие-то передовые методы или общие стратегии для решения такой ситуации?

Answer 1

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

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

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

Продавец предоставлен поставщиком.

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

Это ответственность покупателя при наличии у нескольких поставщиков.

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

Помимо этого, существует еще один ORM (Object Role Modeling, см. VisioModeler, InfoModeler и т. Д.), Который довольно хорошо рассматривает вопрос с реляционной стороны (IMHO).

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

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

Answer 2

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

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

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

Answer 3

Кажется, SOA может оказаться полезным в этом случае. Я специально подразумеваю SOA бизнес-уровня, как описано, например, Bill Poole и Udi Dahan с реализацией на основе событий asabs pub-sub.

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

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

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

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

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

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

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

Надеется, что это помогает :)

Answer 4

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

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

Предполагая среднее крупномасштабный н-уровневое приложение Java на базе, вот мои предложения для среднего уровня и EIS-уровня:

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

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

3. Приобретайте хорошее время для определения правильной детализации методов сервисного интерфейса и зависимостей подсистем.

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

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

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

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

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

Удачи ..!