Думаю надо начать с аддонов и автолодера... Хоть ты и не

любишь лару, я уверен - ты знаешь и представляешь приложение ларавель непонаслышке.
В пиро папка app почти пуста (в ней все равно можно писать, но, ай белив - это лишнее). То же самое можно сказать и относительно содержимого папок database и resources.
The best practice - это держать свой код в аддонах.


АДДОНЫ.

Каждый аддон - отдельный пакет на пакаджисте (при желании на гите), и, следовательно - имеет свой composer.json, в котором и прописан PSR-4 неймспейс для автолодера. Все аддоны, являются наследниками одного класса, и всего их пока 5 видов:

1. Module - представляет из себя неймспейс и раздел в админке. Может содержать несколько моделей (streams), а так же полей (fields). Стоит заметить, что поля, могут быть реюзабл в пределах одного неймспейса (модуля) для нескольких моделей (streams). Использование определенного поля, определенной моделью и называется связью (assignment).

2. FieldType - тип поля служит для определения правил миграции и дальнейшего взаимодействия с БД, для одной ячейки данных у модели. Он содержит тип поля, но может содержать аксессор, мутатор, схему - классы в которых и описываются эти правила. Отношения - тоже описываются здесь (я не имею ввиду прямого указания модели).

3. Theme - тема. Тут особо нечего - бывают двух видов: админка и фронт. Показываются в настройках в админке (хран в БД). Может быть перекрыто последовательно, из нескольких мест в ФС (самое сильное - .env)

4. Plugin - это тупо плагин твиг.

5. Extension - с ним ситуация, как с бубями в преферансе: "не с чего ходить - ходи с бубей". Внутри может быть размещена любая логика. Оно может быть связано по универсальному ключу с другими аддонами, что, по сути, является еще одним способом расширения с наследованием, но речь сейчас не о нем.

Важно, что, несмотря на разделение, благодаря общему родителю, аддоны могут пересекаться классами. Например, не обызательно создавать отдельный аддон для плагина, достаточно создать класс плагина в модуле и подключить его в сервис-провайдере. Это касается почти всего.
Класс сервис провайдера может содержать любой из аддонов.


МИГРАЦИИ и устройство БД.

Платформа стримс имеет свой расширенный мигратор, который способен читать миграции, заданные в декларативном стиле. Файлы миграций создаются автоматически, при скаффолде аддонов определенных типов, а также при скаффолде стрима(модели).
The best practice, если мы говорим о модуле, ИМХО - иметь один файл миграции для модуля, в котором описываются все используемые поля, и по одному на каждую модель - в них описываются параметры моделей и принадлежность к ним полей. Важно, что в любой миграции, могут быть использованы стандартные для Ларавел up() и down() методы.

БД имеет в названиях своих таблиц жесткую зависимость $app_reference, неймспейса и модели.

Структура такова:

applications - "корневая" таблица, она имеет связь с applications_domains и это единственные таблицы, имеющие название без префикса. Все другие таблицы имеют в качестве префикса в названии "{$app_reference}_"

streams, fields и assignments - это "служебные" таблицы. Они содержат информацию о:
- других таблицах с базе и их свойствах (streams)
- полях, которыми имеют возможность обладать таблицы (fields)
- реальных фактах обладания какой-то таблицы, каким-то полем (assignments)

Остальные таблицы имеют жесткую зависимость от описаных выше!

"{$app_reference}_{$namespace_slug}_{$stream_slug}"

А если стрим (ряд) имеет поле translatable === true, то еще и

"{$app_reference}_{$namespace_slug}_{$stream_slug}_translations"

Это не все - могут быть еще вариации конфигураций. Не будем на них останавливаться.

Когда меняется содержимое служебных таблиц (а это модели ларки), наблюдатель триггерит событие Eloquent, которое, в свою очередь, запускает команду - одну из команд - проводящих маленькую миграцию, соответствующую изменениям.

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

Фухх. Можно это будет серия описаний, @fes0r ?

не стоит делать серию, этого достаточно. Ты так и не ответил на вопрос но уже пофиг