Единые сервисы для нескольких продуктов норм или стрем?
Представим, что у нас есть 2 продукта. Телеграм бот и API. API работает с базой данных через сервисы. Телеграм боту тоже нужна инфа. Есть 2 варианта. А - Бот обращается по сети к API, получает данные. Б - Сделать отдельный пакет с сервисами и добавить его как зависимость и API и Боту. Теперь бот может получить данные напрямую из БД через сервисы. При варианте А у нас вроде бы верная архитектура с тз того, что к БД имеет доступ только 1 точка входа - API. При варианте Б мы избавляемся от написания "клиента" для нашего API, которым будет пользоваться бот. Подскажите умные прогеры, какой вариант более правилен?
Нет "правильного" в общем смысле, пока твоя система соответствует поставленным требованиям.
Выпиши в столбик все характеристики системы, которые для тебя важны.
И оцени, оба твоих варианта в контексте этих характеристик.
Назнач каждой характеристике коэффициент важности. Перемнож и сложи - выбери тот вариант, который больше баллов наберёт.
Если ошибешься - ошибку будет найти не трудно, благодаря тому что у тебя будет какой-то четкий алгоритм для принятия решения, вместо вайбиков.
а это реально два продукта или монолит с двумя интерфейсами? если деплой один: Б нормально. Разные хосты/релизы: только А, иначе общий пакет сервисов прилипнет к БД-схеме.