Не надо путать сущность и вью модель. Если этот объект строится для отображения юзеру или внешней системе, то это вью модель.

Сущность это объект домена и торчать наружу из домена он не должен. В первую очередь из-за мутабельности )

про лару незнаю, но вот на yii2 сейчас начинать пилить то, что планируется долго и упорно развивать, кажется плохим решением. Сделать прототип или первую версию, которую всё равно переписывать - тут да, вполне

С ларой, в принципе, можно уживаться, но придется не использовать большое количество ее функционала, иначе весь проект получится полное... Техдолг) Они ж в самом начале гайда пишут о том, что вот настройки приложения можно в рантайме менять, пользуйтесь.

Я не понял

Ну вот у меня у пользователя есть аккаунты TokenUserAccount - по токену, VkUserAccount - через ВК, и думаю вот как обозвать тот, что через логин и пароль :)

Сделать framewrok agnostic прототип, если ориентируешься на переписывание на тот же yii3, и норм. Спрятать все за интерфейсы, в инфраструктурном слое - спокойно юзать контроллеры, AR и прочее.

м... ну может быть. Но это надо хорошо уметь в разделение слоёв

Я у себя в проектах стал все разделять на папки Domain, SubDomain, Infrastructure) В последнюю сую все, что как-то зависит от конкретной реализации чего бы то ни было. В Domain сую сами сущности, интерфейсы id, репозиториев и фабрик.

Здравый подход. Я вот с субдоменами пока не очень осознал как правильно делать

В субдомен всё что не влезло в остальных двух?)

В субдомен - субдомены)

manychat на первом сидит и вроде не собирается никуда пока переползать

Возможно его хейтеры сожрали просто и он выгорел. Тяжело быть одному.

ну и барабан им на шею

да, его в пыхтелке жестко говняли

поэтому разрабатывай коммерческий софт и бед не знай) норм путь

Вот, например, делаю бота для ТГ. Простенький, чисто для практики себе. Функционал: пользователь может создать кошелек, в кошельке - категории, у категории может назначить целевую сумму, добавить или убавить текущий баланс на кошельке. У меня есть "загашник" на отдельной банковской карте, и я хочу учитывать, на что сколько у меня там отложено.
Домен первого уровня - кошелек, категории, пользователь, а также - репозитории и сервисы, которые управляют состоянием всего этого добра. Поддомен - ТГ-клиент для кошелька, у которого также есть свои сущности и сервисы. Я ему даже свой роутинг сообщений написал))
Если зайдет и не появятся другие планы - сделаю еще кросплатформенный клиент на флаттере, для него в бэкэндном репозитории тоже будет свой поддомен.

Я это называю gateway :)
Точки входа через которые идёт взаимодействие с ядром

телеграм, консоль, веб-морда, приложение и что угодно ещё

Я не совсем тогда понимаю, что есть корректный код.
Описанное - это обработка данных от внешней системы. Получать по запросу - надо. Обновлять по событию снаружи - надо. Кэшировать - тоже надо, потому что никто не даст мне дёргать внешнюю систему на каждое обращение.
Для других частей проекта эта логика должна быть прозрачна, их не должно волновать - получены данные из кэша или вытянуты прямо сейчас при первом обращении.
Понятно, что после этого условного репозитория будет ещё сервис доступа к той или иной системе, сервис работы с кэшем и так далее. Оно не всё будет в одном классе, конечно.
Если есть какие-то другие способы разложить логику - то есть ли где про это почитать или погуглить?

Есть ещё вариант "делать но осторожно" ) Отделяя бизнес-логику от фреймворка.

Как в том примере биллинга, ну может не так жёстко разделять а помягче.

Будет не страшно на Yii2, если в любой момент можно соскочить )