@enigma2030

Взаимодействие между несколькими самостоятельными приложениями?

Приветствую всех.

Есть 3 самостоятельных приложения(проекта) (Client, Billing, Order)
Со своими уникальными сущностями, у каждого своя база.

Нужно реализовать взаимодействие между этими приложениями.

К примеру Client создает Order и делает оплату в Billing.

Вариант который сразу приходит на ум это REST API.
Все работает, нужно только рализовать логику обработки запрос/ответ если создание/изменение одной сущности в одном приложении влияет на сущность в другом.

Вариант другой это https://symfony.com/doc/current/doctrine/multiple_...

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

Как вариант можно реализовать взаимодействие через отдельный bundle в котором описать все сущности 3х проектов.

По идее все работает.
Но тут возникает главный вопрос. После изменение логики какой либо из сущности мы должны дублировать эти изменения в bundle.

Возникла идея "залинковать" файлы сущностей отдельных проектов в bundle через symlink

Client: App\Entity\Client -> Bundle: Bundle\Entity\Client
Billing: App\Entity\Billing -> Bundle: Bundle\Entity\Billing
Order: App\Entity\Order -> Bundle: Bundle\Entity\Order

И к примеру обращаться из проекта Client к сущностям Billing и Order через пространство имен Bundle.

Но тут возникает проблема конфликта имен. Файл класса сущности находится, но не может подключиться так как есть расхожения в пространствах имен.

Можно ли как то "переписать" или "подменить" при подключении файла пространства имен или это в принципе сделать нельзя? Не могу корректно сформулировать вопрос чтобы что-то найти по нему.

Один из вариантов https://symfony.com/doc/current/service_container/... но так и не получилось сообразить как его использовать.

Заранее спасибо.
  • Вопрос задан
  • 201 просмотр
Пригласить эксперта
Ответы на вопрос 2
ipatiev
@ipatiev Куратор тега PHP
Потомок старинного рода Ипатьевых-Колотитьевых
Не должно у вас изменение сущности в одном приложении влиять на сущность в другом.

Весь мир с ума сходит по микросервисам, убивается на распилке монолитов.
А у вас они уже есть, но вы хотите слепить из них обратно монолит.
У вас сейчас низкая связанность, а вы хотите ее повысить на пустом месте.

Какая проблема, чтобы Client сходил в Order, получил идентификатор созданного заказа и дернул Billing?
Зачем во всех этих трех сервисах делать тройное дублирование сущностей?
Ответ написан
@roxblnfk
Я, может, с ядерной бомбой в песочницу захожу, но со своей колокольни рекомендовал бы сразу брать Temporal. Особенно, если в проекте есть что-то из:
- запрос на надёжность (работа с деньгами)
- множество сервисов, работающих в контексте общих процессов
- ярко выраженный воркфлоу (сценарий), растянутый во времени или размазанный на сервисы
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы