Насчёт конкретно подхода о котором вы говорите не скажу, скорее всего это плохая идея. Видел пару примеров несколько лет назад, бОльшая часть этих модульных подходов было нечто среднее между недомикросервисного подохода, с примесью разработки composer пакетов и элементами (концептуальными) плагинов wordpress.
Или другой подход где "модули" laravel разделялись пространством имен и особой структурой, с некоторыми костылями для поддержки разделения кода. Этот подход формально лучше, но по факту обычное не нужное усложнение проекта. Но если вам интересно, можете изучить
https://github.com/nWidart/laravel-modules
Но как по мне, если уж и заморачиваться в подобном плане, то скорее наоборот отвязкой максимальной ядра приложения от любого фреймворка framework-agnostic подход.
А так... Главный принцип, в целом кстати во многом пересекается с принципами микро сервисной архитектуры:
есть определенная часть/логика приложения, которая может выполнять свою функцию независимо, которую могут писать разработчики независимо, можно выделить в отдельный пакет. Например, вы придумали свой крутой прокси изображений, и он как-то явно выходит за рамки вашей бизнес-логики приложения, более того возможно он пригодится в ваших других приложениях (или вы хотите поделиться с миром) делайте отдельный пакет.
Ну и конечно у таких пакетов, могут быть зависимости в виде других пакетов.
А вот прям делать декомпозицию приложения на пакеты, ради декомпозиции не стоит. Только если есть конкретный смысл что-то выделить.
Примеры вот хорошие у Spatie
https://spatie.be/open-source?search=&sort=-downloads .
Там же можно посмотреть, как пакеты зависят друг от друга, например image от image-optimizer.
Все их, достаточно популярные, пакеты вышли из практики разработки приложений для клиентов.
Ближе к вашему примеру это проект Nova
https://nova.laravel.com/ и тоже имеет кучу пакетов
https://novapackages.com/ .
Но здесь тоже нужно учитывать, цели самой Nova и почему такая организация. Сама Nova это как бы расширяемый прототип панели управления для CRUD приложений, она универсальная by design, поэтому и нужны доп пакеты, которые закрывают конкретные цели.
Если у вас целевое приложение, то незачем его корневую бизнес логику куда-то выводить.
Простой