@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. Особенно, если в проекте есть что-то из:
- запрос на надёжность (работа с деньгами)
- множество сервисов, работающих в контексте общих процессов
- ярко выраженный воркфлоу (сценарий), растянутый во времени или размазанный на сервисы
Ответ написан
Комментировать
Ваш ответ на вопрос

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

Войти через центр авторизации
Похожие вопросы
YCLIENTS Москва
от 200 000 до 350 000 ₽
Ведисофт Екатеринбург
от 25 000 ₽
ИТЦ Аусферр Магнитогорск
от 100 000 до 160 000 ₽
26 апр. 2024, в 18:27
200000 руб./за проект
26 апр. 2024, в 18:24
80000 руб./за проект
26 апр. 2024, в 18:00
500 руб./за проект