Как организовать переиспользование кода в двух проектах на Laravel?

Question

[motomac]

Стоит задача написать бэкенд для сайта, работающего на две разные страны. На 90% между ними все идентично, но 10% составляет некоторая региональная специфика. Сейчас бэкенды работают как два независимых репозитория (один форк другого). Никакого переиспользования кода нет, и они расползаются все дальше и дальше друг от друга, либо приходится делать каждый раз двойную работу по накатке одинакового функционала.

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

На ум приходит несколько вариантов:

1. Один репозиторий - один сервер, одна БД. Тут проблема с потенциальной невозможностью кастомизации. Код должен 100% удовлетворять требованиям обоим бизнесов;
   
2. Один репозиторий - два сервера. Здесь некая кастомизация конфигами, но в целом то же самое;
   
3. Два репозитория - два сервера. Общее вынести в пакеты.
   

Последний вариант видится наиболее перспективным. Но это легко на словах, сложнее на деле. Что выносить в пакеты и по какому критерию? Основные модели, контроллеры, routes, events, listeners, а локально наследоваться от них? Как быть с миграциями?

Потом раз основная работа общая для обоих проектов, то и обновляться в основном будут именно эти общие пакеты. Т.е. каждый пуш в этот общий репозиторий должен запускать деплой обоих сайтов с последующим `composer update`?

Поделитесь опытом, кто делал нечто подобное.

Answer 1

[vism]

При прочих неизвестных я думаю оптимальный обычно

Один репозиторий - два сервера. Здесь некая кастомизация конфигами, но в целом то же самое;

Тупо в нужных местах проверки через if. Дешево и сердито, а может больше и не нужно будет.
Но конечно специфику учитывать можно и в БД, формулах.
Т.к. условно налог не через if считать, а иметь ставку в БД или конфигах, а подставлять её как переменную.

апдейт
https://tenancyforlaravel.com/
вот, я эту штуку использую.

Comments

[inFureal]

Зло в чистом виде советуешь.
Тут я думаю имеется ввиду какой-то конкретный функционал под уникальные задачи. А пилить все в куче и разделять через условия не очень задумка. Нарушается первый принцип SOLID

[vism]

inFureal, тут уже у кого как получится
Не вижу ничего плохого.
Уникальный функционал уходит в сервисы, разделённые семантически. В зависимости от tenant подхватывается нужный сервис. А чтоб проблем при этом не было, есть интерфейсы.
надо будет 3 tenant добавить - всё легко и просто относительно поддержки 3 разных кодовых баз.

Это по сути простейшая tenant архитектура с разными БД

[inFureal]

vism, тут да, но тогда изначально надо строить архитектуру в это русло, а не пилить "заплатки"

[motomac]

Пакеты для multi tenancy смотрел, но, по-моему, это не мой случай, т.к. там приложения одинаковые для всех клиентов. Кастомизацию под конкретного клиента они не описывают.

[vism]

motomac, Всё от задач.
Я использую на внутреннем проекте ERP системы.
Отдельные базы, чтоб не менять структуру БД.
98% функционала совпадает.
У меня основная разница в БД, разные склады, поставщики, заказы и т.п.

В коде всё сквозное, правильные параметры берутся исходя из ID складов и т.п.
Иногда через switch case.
По хорошему вобще на сервисы переделать, как я выше писал

Answer 2

[Константин Б.]

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