Критерии выбора

Критерии

• Сложность
  • Обоснована ли сложность архитектуры для вашего домена?
  • И наоборот, не слишком ли стиль прост для вашего домена? В этом случае вы рискуете получить систему с нераспознаваемой структурой, так как архитектура не позволит правильно управлять зависимостями.
  • Гибкое тех решение должно быть открытым и усточивым для будущих изменений, но сбалансированное и без overenginering
• Асинхронный обмен сообщениями и итоговая согласованность
  • Асинхронный обмен сообщениями может использоваться для разделения служб и повысить надежность (так как сообщения могут отсылаться повторно) и масштабируемость.
  • Но он также усложняет работу с итоговой согласованностью и может приводить к дублированию сообщений.
• Взаимодействие между сервисами
  • Так как приложение можно разбить на отдельные сервисами, есть риск, что обмен данными между службами приведет к неприемлемому уровню задержек или перегрузке сети (например, в архитектуре микрослужб).
• Управляемость
  • Насколько тяжело управлять приложением, выполнять мониторинг, развертывать обновления и т. д.?
• Слабая связность, сильная целостность
  • Ни одну из текущих ИС не нужно будет дорабатывать под новое подключение ИС к шине сообщений

TODO объединить с атрибутами качества ?