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

В этот момент многие приходят к идее модульности.

Что такое модульность

Если коротко — это разделение приложения на независимые блоки по бизнес-доменам.

Примеры модулей:

- Users - Orders - Payments - Notifications

Каждый модуль — это не просто папка, а полноценный изолированный кусок системы со своей логикой, моделями, сервисами и API.

Плюсы модульности

1. Контроль сложности Проект перестаёт быть “монолитной кашей”. Ты работаешь с конкретным модулем, а не со всем приложением сразу. 2. Изоляция логики Логика заказов не смешивается с пользователями. Это сильно упрощает поддержку и рефакторинг. 3. Параллельная разработка Разработчики могут работать независимо друг от друга, не залезая в чужие части системы. 4. Масштабируемость Это хороший шаг в сторону modular monolith или даже микросервисной архитектуры. 5. Переиспользуемость Грамотно сделанный модуль можно вынести в отдельный пакет.

Минусы, о которых редко говорят

1. Сложность на старте Если проект простой — модульность может только навредить. 2. Оверхед Появляются интерфейсы, абстракции, дополнительные слои. Код становится больше. 3. Псевдомодульность Самая частая ошибка — просто разложить код по папкам и назвать это архитектурой. Если модули напрямую дергают друг друга — это не модульность. 4. Дублирование Без нормальной архитектуры общая логика начинает копироваться или превращается в свалку в shared-слое.

Как организовать модули

Главный принцип — делить не по слоям, а по доменам.

Плохо: - все модели в одном месте - все сервисы в другом

Хорошо: - каждый модуль содержит всё, что ему нужно

Пример структуры:

Modules/ - Users/ - Orders/ - Payments/

Внутри каждого — свои модели, сервисы, контроллеры и т.д.

Как модули должны взаимодействовать

Вот здесь чаще всего ломают архитектуру.

Плохой вариант: - прямая зависимость - один модуль использует классы другого напрямую

Это создаёт жесткую связку и убивает гибкость.

Правильный вариант — через контракты (интерфейсы): - объявляем интерфейс - реализуем его внутри модуля - подключаем через DI

Модуль не должен знать как устроен другой модуль. Он должен знать только что тот умеет делать.

В итоге модули можно менять, не ломая остальную систему.

Альтернатива — события

Если хочется ещё меньше связности, можно использовать события.

- один модуль сообщает о событии - другие модули сами решают, реагировать или нет

Плюсы: - слабая связность

Минусы: - сложнее понимать поток выполнения

Золотые правила

- Модуль = бизнес-домен, а не технический слой - Минимум знаний о других модулях - Никаких прямых зависимостей - Взаимодействие через интерфейсы или события - Shared-слой — аккуратно, без превращения в свалку

Когда это действительно нужно

Стоит внедрять, если: - проект растёт - сложная бизнес-логика - несколько разработчиков

Не стоит, если: - простой CRUD - один разработчик - нет требований к масштабированию

Вывод

Модульность — это не про папки. Это про границы и контроль зависимостей. Хорошо сделанная модульность упрощает жизнь. Плохо сделанная — делает проект в два раза сложнее без какой-либо пользы.

Всем добра )