Единые сервисы для нескольких продуктов норм или стрем?

Question

[Nick331045]

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

Comments

[nozd up]

Если "сложность" позволяет идти по пути А - придерживайтесь его. По описанию к варианту Б нужно будет переходить, когда вы начнёте БД разделять для API и для бота (со всеми вытекающими).

Answer 1

[Василий Банников]

Нет "правильного" в общем смысле, пока твоя система соответствует поставленным требованиям.

Выпиши в столбик все характеристики системы, которые для тебя важны.

И оцени, оба твоих варианта в контексте этих характеристик.
Назнач каждой характеристике коэффициент важности. Перемнож и сложи - выбери тот вариант, который больше баллов наберёт.

Если ошибешься - ошибку будет найти не трудно, благодаря тому что у тебя будет какой-то четкий алгоритм для принятия решения, вместо вайбиков.

Answer 2

[Пума Тайланд]

а это реально два продукта или монолит с двумя интерфейсами? если деплой один: Б нормально. Разные хосты/релизы: только А, иначе общий пакет сервисов прилипнет к БД-схеме.

Answer 3

[Василий]

шаринг БД это антипатерн. Если в этом есть смысл используете в общем смысле нет.