хотя нет, плохая диаграмма, щас ещё поищу

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

транзакции не просто так могут быть вложенными)

Спасибо. Основной вопрос в том, что сохранение агрегата - подразумевает одну транзакцию. Несколько кейсов = несколько сохранений агрегатов = несколько отдельных транзакций. Норм ли обернуть все это одной бд транзакцией поверх всех юзкейсов? Или я путаю транзакции в бд с какими то еще транзакциями, про которые говорят в контексте агрегатов?

Саги

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

Но из нескольких юзкейсов

если тебе нужно ходить на 2 разных сервиса -- это не атомарная операция

Она может казаться атомарной на уровне клиента

Ну они в рамках одного сервера. И мне надо выдать ошибку пользователю сразу.

так и задача сделать его атомарным)

Вопрос по построению схемы бд. Что считается лучше:
1. Определять “тип” юзера по полю “тип” в самой таблице юзера
2. Определять “тип” юзера по наличию соотвествующей связи. (Записи в соотвествующей таблице)

И как понять, по каким критериям выбирать дизайн.

user:
  id
  //Нужен ли тут userType?
company:
  id
  userId
  TIN
  someAnotherCompanyInfo
team:
  id
  userId
  typeOfActivity
  someAnotherTeamInfo
auth_email:
  id
  userId
  email
  password
  …
auth_phone:
  id
  userId
  phone
  …
auth_facebook:
  id
  userId
  facebookId
  …

Ок. это делается через саги энивей. Выглядит так:
1. Юзер кликает на кнопку
2. контроллер принимает запрос и запускает сагу
3. контроллер ждет событие завершения саги
4. контроллер отвечает http запросом что все ок или нет

Не, конечно можно сделать сагу, конпенсацию - но если в этом смысл в такой задаче?

ты ж программист, а не мы)

Ок, пусть это будет сага, но внутри нее можно обернуть транзакцией или делать именно конпенсационные действия и прочее?

Я хочу послушать советы опытных :)

моя сага не про компенсационные действия, а про оркестрацию.

Я бы ставил юзерроли и от них плясал.

Типа сначала запрашиваем user и смотрим на userRole, а дальше делаем запрос к другой таблице уже?
Не является ли userRole дублированием? У нас уже уже есть связь и мы можем по ней понять role юзера