это функционал логирования, не надо никаких ссылок ни в какие классы, нужно обычное логирование, показывающее кто, что и когда делал

конкретная реализация логирования/аудита зависит от проекта, требований, хостинга и прочих вещей. В системе, имеющей требования к безопасности, логируются все действия пользователей, что-бы можно было воссоздать кто, что и когда делал. В случае WebAPI к примеру можно логировать все вызовы эндпоинтов с указанием юзера, времени, айпишника, параметров итд, дальше есть тулзы для анализа этих логов. Если под "распечаткой" инвойса подразумевается вызов эндпоинта WebAPI то это уже было-бы достаточно для реализации данного требования.
Если таких требований нет, а все что нужно - это администратору по клику одной кнопки выдать кто и когда распечатал какие инвойсы - то можно прикрутить свой аудит, только зачем новый проект-то? Создаешь таблицу аудита и сохраняешь в нее когда инвойс "распечатывается" из контроллера, сервиса или как там у тебя солюшн собран

все ты правильно писал - не надо тащить Identity в бизнес слой, ему там совершенно не место и при переходе на новую версию тебе придется редеплоить сборки с бизнес слоем, за такие вещи даже джуниоры по ушам получают на код ревью

IdentityUser к бизнес логике не имеет никакого отношения, это идентификация и авторизация юзера вызывающего эндпоинт, а вопрос заданный топикстартером - это классическое логирование/аудит и решается как я уже написал сверху, сборка с доменными классами тут вообще не затрагивается, и уже тем более в нее не пихаются зависимости принадлежащие авторизационному слою web api. За класс инвойса, содержащий клеймы пользователей можно далеко не только по ушам получить


что за очередной поток сознания? Какой ОРМ? До тебя не доходит, что обновив авторизационные зависимости слоя api ты вынужден ребилдить бизнес слой?

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


Вот к чему приводит твое полное непонимание ООП - клеймы пользователей в инвойсе это нарушение первой-же буквы в слове solid, тут даже уже не джуны, а студенты-практиканты таких ошибок не допускают


очередная каша из терминов и подходов, которые ты не понимаешь и даже не пытаешся разобраться. Для начала, что-бы уйти от майкрософтовского Identity не обязательно использовать внешний сервер авторизации - ничто не мешает генерировать токены в своем собственно сервисе. Более того, ничто не мешает написать свой собственный велосипед на куках (без Identity), все это - детали реализации авторизационного слоя никак не связанные с работой остальной системы. Можно использовать куки, можно токены собственного производства, или сгенерированные identityserver, или от OAuth, Okta, Azure B2B или многих других - все это инкапсулировано в авторизационном слое и не имеет никакого отношения к остальной системе.
А SSO это вообще из другой оперы - эта технология позволяет получать токены без ввода пароля на сервере авторизации, просто на основе наличия авторизации от другой системы, к примеру залогинившись в gmail ты получаешь доступ к youtube т.к. последний автоматически выдаст тебе токен на основе авторизационной куки (полученной в ходе авторизации на gmail), с "абстракцией от слоя авторизации" это никак не связано, как и с обсуждаемой тут проблемой

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