Поиск совокупного идентификатора на основе зависимости

Насколько я понимаю, у вас есть связь от агрегата B к агрегату A. Такие отношения нормальны и возникают постоянно.

Примечание. Поскольку этот вопрос носит очень общий характер и не имеет контекста, я могу что-то упустить. Если есть более частный случай, чем описанный, сообщите мне об этом.

Это отличное чтение для агрегированного дизайна

Примечание. Прежде чем читать оставшуюся часть ответа, посмотрите это видео от Мартина Фаулера. , Я настоятельно рекомендую его, поскольку он очень подробно объясняет концепции, связанные с событиями и командами.

Примечание. Поскольку термин "объект" также очень важен, я больше не буду использовать агрегат, поэтому предположим, что каждый объект (Игрок, Пользователь, Game) являются корнем своего собственного агрегата и являются границей согласованности, поэтому в этом случае будет использоваться согласованность в конечном итоге по событиям домена. Я также буду игнорировать CQRS в данный момент, чтобы не говорить о стороне чтения и стороне записи. Мы обсудим и реализуем Модель

Возьмем пример с игрой. У вас есть Игрок, который должен представлять Пользователя в Игре. Сущность Player должна каким-либо образом ссылаться на игру и пользователя. Это может быть по прямой ссылке или по ID. В случае распределенной системы это будет по ID. В нашем примере. Давайте использовать UUID (например, 8d670541-aa51-470b-9e72-1d9227669d0c) для идентификаторов, чтобы мы могли генерировать их случайным образом без необходимости определять схему, автоматически генерировать порядковый номер (как в базах данных SQL ) или специальный алгоритм. Допустим, у пользователя есть статистика пользователя. Поэтому, когда Игрок набирает очки (например, убивая других игроков в стрелялке), должна быть создана и обновлена ​​сущность UserStatistics, если она не существует. Статистика пользователя также должна ссылаться на пользователя по идентификатору, поэтому мы имеем зависимость от статистики пользователя к пользователю.

Статистика пользователя будет выглядеть так:

UserStatistics {
  UUID UserID,
  uint KillsCount,
  uint GamesPlayedCount
}

Поскольку проигрыватель не может существовать без пользователя, сначала необходимо создать пользователя. Поскольку Игрок является частью Игры, это означает, что сначала должна быть создана Игра. Давайте определимся с терминологией в нашем Универсальном языке. Пользователь присоединяется к Игре, становясь в ней Игроком. Предположим, что Игра будет создана кем-то другим, а не Пользователями, чтобы избежать обсуждения ситуации, когда Пользователь создает игру и должен присоединиться к ней одновременно и т. Д. Если это произойдет в той же транзакции и т. Д. Игра будет чем-то вроде MMO, где она создается кем-то, и к ней могут присоединиться обычные пользователи.

Когда Пользователь присоединяется к Игре, создается объект Игрок с userID и gameID. Создание Player без userID и gameID недопустимо.

Player {
  UUID GameID,
  UUID UserID
}

UserJoinedGameEvent {
  UUID GameID,
  UUID UserID,
  UUID PlayerID
}

PlayerMadeKillEvent {
 UUID UserID,
 UUID PlayerID,
 UUID GameID
}