Луковичная архитектура в компоновке backend-приложения и куда в итоге класть маперы

Если использовать ЯП где можно запретить использовать сущность за пределами сервисов - имеет право на жизнь.

Но такое умирает в любой момент когда разработчик имеет возможность использовать анемичную модель за пределами сервиса

DDD против реальности: распространённые ловушки и их решение в NestJS

В классическом DDD традиционно выделяют несколько слоёв.

Самоя популярная ошибка в начале статьи. DDD (ни тактический, ни стратегический) не слышал никогда о каких то слоях..

Вы смешиваете DDD и луковичную(слоистую) архитектуру - не надо так.

Генерация диаграммы «Сущность-Связь/ Entity-Relationship» с помощью Laravel

Любая visual tool for database(phpstorm, workbench, etc) умеет это. Зачем целый пакет ставить?

Луковичная архитектура в компоновке backend-приложения и куда в итоге класть маперы

Анемичная модель более точно моделирует предметную область

Вы точно ничего не перепутали в определениях?

Анемичнвя модель и моделирование предметной области - несовместимые вещи.

Луковичная архитектура в компоновке backend-приложения и куда в итоге класть маперы

Отправить из сущности (передав callable в метод user->sendEmail() - это полнота модели. Но такой полнотой нарушается чистота модели. В зависимости от разных кейсов следует двигаться весы в пользу чистоты или полноты. Все трейдоф.