Пролистал ленту увидел ответ. Спасибо

Не знаю могу ли задать вопрос по теме выше сюда. Но я попробую. Если нужно переместить скажете удалю

А вот вопрос. Есть модуль payments, который содержит в себе финансовую логику. Некоторые наборы транзакций.

Есть также в системе несколько модулей которые так или иначе требуют финансовых операций,  один из них реферальная программа.

По логике реф программа отличается от других платежей набором транзакций и логикой формирования платежа. (Структура данных не меняется)

Так же и другие модули.
Собственно вопрос - чья зона ответственности формировать транзакции и логику создания платежа.

Я как раз под это писал свой биллинг )

Должно быть две части, для хорошего разделения.

Одна часть "базовая" и не зависит от модуля или юзкейса. Грубо говоря, она умеет только перечислить N денег со счëта X на счëт Y, выдать баланс по счëту.

Вторая часть будет в модуле конкретного юзкейса и описывает логику выполнения транзакций в терминах бизнеса, не заботясь о низком уровне. Мы решаем кто кому сколько должен, а потом дëргаем метод базового биллинга для осуществления перевода.

Такая структура способна покрыть любые сценарии и оставаться простой в использовании.

У тебя будет модуль Money, который осуществляет перевод и выдаëт баланс, а также модули Payment и Referal которые используют Money.

Хах, у меня тоже свой модуль на эту тему есть) Правда, так нигде и не пригодился пока 😂

Думаю что он кардинально отличается от моего )

Покажешь?)

Интересное мнение. Спасибо

Сейчас уже не за компом, но я скидывал ссылку на прототип.

Ценность этого биллинга вовсе не в коде, а в тех принципах которые я в него заложил.

Следование им по моему мнению позволяет изящно решить любую реальную задачу.

Ничего сверхъестественного и нового я не придумал, просто изучил какие ошибки делают проектировщики биллингов и стало ясно как сделать правильно.

Структура, конечно зависит от, собственно, того, что за приложение создается.
Мы занимаемся в основном системами ERP. в которых работники работают за своими рабочими местами.
Каждое рабочее место оптимизировано для того, чтобы в нем было удобно делать именно ту работу, для которой оно предназначено, ничего лишнего там быть не должно.
Таких рабочих мест даже в большой системе не очень много - максимум пара десятков.
Эти рабочие места и что с ними связано, у нас организуются как модули.
Также: в системе бывают "группы сущностей" - это набор таблиц, объединенных некой общностью.
Например, client, client_type, client_status, client_comment, client_phone, client_email - это все группа сущностей client.
AR модели с этими группами сущностей лежат каждая в своей папочке в корневой папке model. В основном в этих моделях указаны те вещи, которые будут нужны при использовании сущности в любом модуле.
Например, некоторые общие правила валидации, аннотации phpdoc, реляции и тому подобное. при использовании в каком-либо модуле, в этом модуле размещается модель, наследуемая от соответствующей вышеописанной.
Сами вышеописанные модели наследуются, в свою очередь, от Базовых моделей и,  иногда, включают в себя трейты с нужным функционалом.
Базовые модели, в свою очередь, включают в себя некоторую очень общую функциональность - например, код: связанный с реализацией доступа с применением политик защиты строк.
Модули используют в своей работе свои собственные контроллеры, однако, если при работе появляются ситуации, когда одна операция с сущностью происходит в нескольких модулях (или по наитию архитектора), экшен переезжает в Контроллер группы сущностей, расположенный в корневой(для приложения) папке.
Работы с некоторыми сущностями "для внутреннего пользования" происходит через Сервисы(Провайдеры), оформленные как компоненты приложения.
Все вышесказанное, наряду с нестандартной структурой БД, позволяет создавать легко поддерживаемый быстрый код, мы практически не сталкиваемся с ситуацией, когда необходимо что-то серьезно переделывать для добавления неожиданного функционала, Мы не переделываем: а ДОДЕЛЫВАЕМ.
Да, еще одна особенность - мы почти не используем view - в каждом модуле один view - вида <div id="<module-name>-react-root"></div>
Весь фронтенд - исключительно на react (ну или  редко vue)

Пичалька) Но я нисколько не против этого безобразия)

Нифига тут простыни. Читать стоит?

То есть фронтент все-равно внутри бэка ? Только модули реакта рендерятся в зависимости от аьюхи?

Да, в каждом модуле есть папка фронтенд и в ней react-приложения для этого модуля

Вебпаком пакуются ?

Всякие идеи построит систему по принципу backend-restFul Api — frontend проект с перспективой получить еще и АПИ мы не любим. Красивая идея на практике приводит к куче компромиссов, а компромиссы мы не любим.

Да.

Ну а каким образом реакт с бэком общается ?

Если нужно что-то спросить