Стоит ли использовать soa/msa?

Question

[GizzaProger]

Стоит ли использовать в нашем приложении использовать soa/msa?
У нас есть почти монолитное приложение (фронт и бек отделены + сервисы для текстового чата и видео чата). В рамках этого приложения есть система продаж и скидок. Наш заказчик хочет сделать личный кабинет для участников реферальной программы, вернее для тех, кто распростроняет купоны на скидку.
В ЛК участник программы должен иметь возможность просмотреть свои продажи (продажи свои когда был применен купон реферала)
Для того, чтобы не увеличивать основной бек - основной сервис, я хочу сделать отдельный сервис для реферала. Все калькуляции и запросы должны быть реализованы в этом сервисе. Он будет иметь право только на чтение основной базы. Для записей у него будет своя база

Какой профит я хочу получить?
1) Никаких изменений в основном приложении
2) Разработку можно поручить не основной команде разработчиков
3) Если новый сервис напишут плохо, то это никак не скажется на основном сервисе

Какие минусы я вижу:
1) Мне не нравится, что будет серьезная зависимость от структуры БД, а значит и от основного сервиса
2) Сложности с авторизацией и разделением прав. Сейчас реализованы права в основном сервисе
3) Увеличение стоимости разработки

Подскажите, пожалуйста, есть ли еще какие-то проблемы если выберу данный способ реализации?

Мне он очень симпотизирует, но я боюсь слишком усложнить систему

Comments

[GizzaProger]

UPD: посчитал, что делать отдельный сервис - это дорого и в дальнейгем не удобно по сравнению с тем, чтобы впилить этот функционал в основной сервис

Answer 1

[Владимир Коротенко]

Я бы сделал еще более изолированно. В основном сервисе создал бы rest endpoint. Рефералка будет только знать его и получать все данные. Избавляетесь от знания структуры базы в проекте.

Comments

[GizzaProger]

Я думал над этим, но тогда вносятся изменения в исходных сервис, а я не хотел бы этого. Может я и ударился в крайности, но не хочу вообще никак менять исходный сервис
Есть вообще вариант сделать отдельный сервис для работы с бд и формированием сущностей. В нем как раз будет реализованы rest методы. Но это уже что-то совсем овер-инжиниринг)

[Владимир Коротенко]

GizzaProger, Плохой вариант. Вместо 2 проектов 3 и все равно базу нужно помнить в 2 проектах.
В моем случае сохраняется независимость 2 проектов, они остаются целыми без магических знаний о структуре бд, каждый проект знает только свой контракт.
То есть банальное
в базе у вас хранилось что то типа Fullname потом поменяли на Firstname Lastname MiddleName
нужно менять в 2 проектах и еще оповещать команды и синхронизировать время выкатки.

В моем варианте просто в головном варианте правится запрос и поле Fullname просто передается как и передавалось. Команда 2 проекта даже не знает про это

[GizzaProger]

Владимир Коротенко, Верно

[GizzaProger]

GizzaProger, А как можно решить проблему с ролями и авторизацией без лишних серисов?
Самый простой вариант приходит в голову - использовать тот же токен, что и в основном сервисе и туже авторизацию для получения токена

[Ross Alex]

GizzaProger, токен, ограничения по ip и т.д.

[GizzaProger]

Ross Alex, Спасибо