Как в вашей саге будет обрабатываться такой кейс: сервисзаказа подсвердил заказ, но потом сервисДоставки выдал ошибку?
Я вижу два варианта: 1) в саге обертка БД транзакцией 2) В  саге после ошибки над доставкой идет обращение к сервисуЗаказа чтобы отменить прошлое действие.

для чего в company и team userId?

Не является. Юзерроли отдельно, а наличие для них данных отдельно.

я так понял вы про https://blog.devart.com/table-per-type-vs-table-per-hierarchy-inheritance.html
есть и другие варианты, думаю проще погуглить как из них выбирать
если коротко, то важно как вы будете по ним искать, а точнее будут ли разные типы в одном контексте использоваться обобщенно, для пользователей это чаще всего не так и вы хотите table per type

Потому что юзер может быть либо company либо team

Данных у пользователя может ещё не быть. Или наоборот, роль может быть временно выключена.

У меня создается сразу нужный тип юзера. Либо company либо team либо какой-то другой

Спасибо, почитаю

Ну может быть в некоторых архитектурах прокатит.
Но в целом может не прокатить.

Всегда нужно уточнять у бизнеса, как нужно обрабатывать такие ситуации.
Допустим вариант 1. отменять все нахер и слать юзера с ошибкой
Тогда нужно, чтобы сервис заказа умел отменять только что подтвержденный заказ.
т.е. он должен понимать две команды: подтвердить заказ и отменить только что подтвержденный заказ.

Есть вариант 2, попытаться повторить. Наиболее популярный.
Сценарий:
1. отправить команду подтвердить заказ
2. отправить команду в сервис доставки
3. получить оба ивента что все ок. и тогда завершить сагу новым ивентом, что заказ "подтвержден окончательно"
4. если какой-нибудь из сервисов отказал, то ждем N милисекунд и повторяем
5. если все отвалилось по техническим причинам, то юзеру следует сказать, что ваш заказ сохранен, но доставка еще не известна.

https://www.entityframeworktutorial.net/code-first/inheritance-strategy-in-code-first.aspx
вот тут нормально написано с плюсами и минусами подходов

Но это лишь варианты решения кокторые пришли на ум. их реально очень много

Транзакции ко всяким базам данных должны жить только в рамках 1-й команды к аггрегату или чему-то еще.

Те по сути нормализация не Священный Грааль? Надо отталкиваться от потребностей?

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

Спасибо за развернутость! Т.е. так или иначе это конпенсационные действия, но уже в зависимости от бизнес логики.  Транзакцией БД поддерживать атомарность перехода состояний нескольких агрегатов - не хорошо.

конечно

Не хорошо, но допустимо 😅

Серебряных пуль нет, есть обычные, которые надо заряжать и делать 4 выстрела в минуту во время дождя.

не хорошо, но возможно. сложно объяснить на пальцах