Я работаю над созданием системы обмена сообщениями в облачной среде веб-сервисов Amazon. Мы можем использовать либо SQS, либо любые другие AMQP-системы, такие как RabbitMQ. Решение может быть принято позже, но дизайн должен быть достаточно прочным, чтобы позже поддерживать базовую систему обмена сообщениями. Решение о базовой системе будет принято позже на основе плюсов и минусов каждого из них, что не вызывает большой озабоченности по сравнению с Теперь.Шаблон проектирования для нескольких систем обмена сообщениями в облачной среде
Так как это должна быть модель Продюсер/Потребитель, я обнулял шаблон стратегии для клиента/производителя сообщений, который будет использовать Spring beans для правильной реализации стратегии на основе выбранной системы. Мой вопрос в том, есть ли другой шаблон, который подходит для этого случая, может быть адаптером. Почему или почему нет или есть стратегия, лучшая модель для этого случая?
Спасибо за любые входы !!
-Tatha
Трудно сказать. Вы изучили easynetq или другие структуры, которые поддерживают общие случаи (производитель/потребитель, публикация/подписка, запрос/ответ)? Это может дать вам хорошую идею для принятия решений. – Miguel
Спасибо, посмотрим в другие рамки. – Tatha
Нам нужно больше деталей. Многие шаблоны - это решение проблем, связанных с возможностью изменения изменчивости, но с затратами на сложность, количество модулей и т. Д. Каковы API-интерфейсы, например, для разных систем обмена сообщениями? Адаптера может быть достаточно, если API-интерфейсы систем обмена сообщениями просты. Сколько будущих систем вы хотите поддержать? Если шансы высоки, их будет больше двух, тогда картина может стоить того. Если это всего лишь два, и это просто обмен сообщениями, насколько уродливым будет условный код? Не забывайте, что если вы идете со стратегией/адаптером, вам понадобится простая фабрика или DI. – Fuhrmanator