Я посмотрел в сторону ddd чтобы упростить наращивание логики и работу с объектами

Ну если это первое решение ваше "по ddd" и вы хотите его "быстро" сделать, то вряд ли тут профит будет, если честно. Начните с простого - избавьтесь от анемичных моделей, можете для старта актив рекорд даже заюзать. Немного srp.
Вот эти вот агрегаты, как мне кажется, дадут на данном этапе только проблемы

Начни с самых простых улучшений. Разбиение на функции например

Перепишем по ддд... Сколько глупости в этой фразе))

Ты лучше посмотри внимательней на код, который написан. Может его тоже уже по ДДД переписывали))

Непонятно, какой профит ожидается

Ну это я понять могу.
Хочется же работать с приемлимым для тебя кодом.
А не говорить, ну да, каждый день пачкаю руки в дерьме, ненавижу этот говнокод, ну а что поделаешь, не переписывать же))

Лучше по grasp тогда переписать

К слову если игрушки и фапать на производительность то можно про принцип локальности данных почитать

Хотя конечно "ходить в базу" в этом ключе уже нарушение. Можно функции процедурки разве что

Есть application services/use cases подскажите как и где делать проверки авторизации прав доступа у пользователя на выполнение use case, если use case может выполняться через консоль, веб и апи?

Авторизовывать в не use case и передавать уже в use case объект пользователя с нужными правами?
Не знаю как это делать через консоль. Передавать  id пользователя в консольной команде?

Не дели на use/application. Просто старайся юзать SRP, а там может тебе и одного слоя хватит

Use cases это и есть SRP, только на уровне архитектуры, а не класса ))

Я как раз про то, что нет смысла разбираться что usecase, а что app. Если начать анализировать с точки зрения SRP - становится понятно что куда. Абстрактно что то отнести к чему то нельзя, тк зависит от кейса

Мы то за консольный интерфейс где требуется авторизация?

На уровне ui

В контроллерах и консольных командах? 😬

Например сценарий удаление пользователя. Удалить его может сам пользователь или модератор, админ. Если делать проверки прав на уровне ui, это не может привести к потенциальным ошибкам, если где-то пропустить, а где-то не правильно сделать проверки прав? 😌

use case/application service это один и тот же класс, я ничего не делил. Просто в DDD и чистой архитектуре именуется по разному.

Ну давай думать. Допустим у тебя есть юзкейс - отредактировать юзера. Ему в целом должно быть плевать кто выполняет операцию. На вход просто поступает "кого менять и чё менять".

И есть два api эндпоинта например, один для модератора и другой для пользователя. У одного свои правила у второго другие.

Если операция приходит из внешней системы - там третьи правила. С cli сложнее ибо там обычно авторизация не нужна (ты уже залез на сервер условно и тебя уже не остановить)

Тот же srp что бы уважить как раз и стоит держать все это отдельно

Я бы то, что ui специфично отнес к ui. А так в use case. Те то, что уже не зависит от типа UI. Можно обернуть функцию use case в проверку роли