Сложилось впечатление, что ты не совсем понимаешь, что такое Use Case. Use Case - это какой-то бизнес сценарий, состоящий из от 1 до n шагов. То, что, как мне показалось, ты описываешь, это - "Interactor" a.k.a Паттерн "Command", он и является шагом юзкейса.
И вот у меня назрел вопрос - как реализовать класс под какую-то сущность в доменном слое, если эта сущность используется во многих юс-кейсах,
Зависит от сложности твоего домена, можно нарезать твое приложения по юз кейсам и сделать из каждого юз кейса отдельный модуль, в котором будут находиться доменные сущности хранящие только те данные, которые нужны юз кейсу.
Например - формирование 'досконального отчета' по списку сущностей
Это непохоже на interactor, interactor как-то меняет состояние системы, а это просто получение данных, тут, в общем-то, и доменные сущности не нужны, скорее просто какой-нибудь интерфейс к бд, которые собирает твоей "отчет".
при этом нужно помнить о перфомансе - тянуть все поля абсолютно во всех юс-кейсах не правильно
Это абсолютно нормально. Если ты будешь делать описанные тобой костыли, ты не получишь буста по перфоманусу, т.к это экономия на спичках, зато получишь код, который сложно будет поддерживать.
вроде как нарушается O из SOLID.
Open–closed principle вообще никак не связан с тем, что ты описал.
Если интересно почитать про то, как организовывать доменную модель, советвую почитать "Шаблоны корпоративных приложений. Мартина Фаулера" и что-нибудь про DDD.
