Можно объяснить то что вы спросили про абстрактность лучше:
Уровень абстракции наоборот - уровень детализации. И мы хотим всегда оставаться достаточно конкретными чтобы понимать что происходит зная о том как это происходит как можно меньше.

Если у вас в интерфейсе рядом 2 кнопки - "отправить сообщение на email" и "сохранить заказ в бд", то пользователь спросит вас - что такое бд?

Или если пользователю на сайте показать просто цифру 404, то ему нужно будет подумать о деталях которые его волновать не должны, а именно о том что такое http и какие статус коды есть. Заменив 404 на "страница не найдена" мы снижаем детализацию, при этом ответ все ещё достаточно конкретный, т.к. пользователь знает или может догадаться что на сайте есть страницы, по аналогии с книгами.

И мы всегда хотим чтобы всё что мы показываем пользователю было понятным и не требовало дополнительных источников знаний, будь то документация или гугление.

Точно так же когда мы пишем код, мы хотим чтобы открывая проект, файл, класс или функцию мы могли не смотреть в другие файлы/классы/etc, а так же чтобы когда мы хотим что-то добавить мы ожидали что в контексте на который мы сейчас смотрим есть (инкапсулировано) всё что нам нужно. Так же если мы не ожидаем чего-то увидеть в этом файле, то мы бы банально не стали это в нем искать.

Так же с разделением по слоям, мы ожидаем, что в центре домена есть "сделать бизнесу хорошо", а чем дальше мы от центра тем больше деталей "что значит сделать бизнесу хорошо? - соблюдать такие-то такие-то бизнес правила" будет обозначено. Переходя к слою приложения мы уже можем не думать о том что конкретно делают те или иные бизнес правила, нам достаточно знать их названия, и эти названия должны образовывать язык который будет на столько простым, чтобы всё что мы хотим сказать можно было выразить одним словом, словом понятным для нас и бизнеса без уточнения деталей(без поиска определения в словаре, где используется слова из "другого" языка).

Спасибо за развернутость! Надо обдумать, пока что-то еще больше запутался )

если понимать это, то кристализуется и понимание вещей вроде "протекания абстракций" и почему использование сущностей в контроллере при наличии юзкейсов на прямую - это протекание абстракций)

а юзкейс (я не уверен, что понимаю что это) нужен - для реюза кода между контроллерами чтоли?

Это app service(либо интерактор, хотя я бы воздержаться от приравнивания интерактора юзкейсу). Он нужен скорее для размещения бизнес логики сильно сцепленной с кодом приложения. В противовес бизнес логике домена.

Если мы хотим использовать несколько юзкейсов в двух контроллерах в большей части случаев мы на самом деле хотим создать юзкейс который включает эти юзкейсы или расширяет один из них. Единственное исключение это наверное сужение данных в контроллере, но это специфика бфф(или когда у нас нет такого разделения).

Вернее даже сказать что юзкейс это контракт для сервиса, чем сам сервис.

По этому юзкейс это часть домена, а его реализации в слоях ниже. Но имхо в чистой архитектуре есть нестыковки подобные этой, и понять в чем все таки соль не реально.

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

грубо говоря, такой вот фасад вокруг домена

а вот это холиварная тема, до сих пор ходят споры, может ли юзкейс использовать другие юзкейсы

абстрактно в вакууме этот впрос не имеет смысла.

У меня есть "юзкейс" когда один "юзкейс" использует несколько других вполне конкретных операций. И я не виду в этом ничего эдакого. просто оркестрация над оркестрацией

Вот тут тоже не совсем согласен. То что ты вызываешь какую-то последовательность методов с разных доменных сервисов и/или кидаешь их результаты из одного в другие, это не логика как бы, а просто её использование.

юзкейс и его реализация это как раз таки оркестрация, там не должно быть логики. вся логика (ифы) делигируются ниже.

Угу, я про это. Потому не считаю что юзкейс это доменная логика.

Назови команду, юзкейс или даже сложную кверю

идеально юзкейс считается как сценарий.

Юзкейс: возьми с полки пирожок

- подними жопу
- протяни рук
- возьми пирожок

а все ифы "а если я уже стою" и прочие "а если пирожок уже взяли" спрятаны ниже

обычно его пихают в application layer.

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

но я дико ненавижу эти концепции со слоями потому что они путают людей