Совет по разделению частей веб-приложения на Java

Я создаю веб-приложение Java, которое прогнозирует цену биткойнов. У меня есть 3 важные части:

  1. Веб-стек (Spring + Thymeleaf + Hibernate)
  2. Часть, которая анализирует API и сохраняет цены BTC в базе данных
  3. Модель машинного обучения, которая берет данные из базы данных и автоматически обновляется.

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

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

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


java web-applications web-application-design
person Levon Minasian    schedule 02.07.2020    source источник

Ответы (1)


arrow_upward
1
arrow_downward

ИМХО

Вы поднимаете два разных аспекта

  • «Пакетный вопрос» - это организация / модульность кода.
    Это помогает сохранить модульность кода, так что вы можете отдельно создавать и тестировать части кода, не связанные напрямую.

  • «Внутренняя ошибка сервера не должна останавливать ML». Это решает, сколько компонентов / подкомпонентов среды выполнения - вы используете.
    В вашем случае - похоже, что есть 2 службы - UI и ML.
    Вы можете запустить, выбрать запуск

  • 1 приложение с 2 сервисами (как вы сейчас делаете)

  • или 2 отдельных приложения с 1 услугой каждое

    В зависимости от сложности, требований времени выполнения и т. Д. Вы можете выбрать либо

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

Примечание: если сервисы достаточно надежны для обычных случаев использования, вы можете жить с одним приложением.

Если вы выберете 2 разных приложения (по одному для UI и ML), имеет смысл разделить код на 2 подпроекта.

  • UI
  • ML
  • вопрос об общем коде (как 3-й) должен быть решен на основе количества совместного использования кода (я предполагаю, что ML легче в БД)
person PrasadU    schedule 02.07.2020
comment
Хороший братан. Теперь я понимаю. Спасибо! - person Levon Minasian; 02.07.2020