хороший вопрос))) потому что у меня такая абстракция)) в рамках которой мне проще взять uuid v5 вместо surveyId.respondentId

хороший вопрос))) потому что у меня такая абстракция)) в рамках которой мне проще взять uuid v5 вместо surveyId.respondentId

В php-service-bus в примере именно отдельная таблица стримид и кому он пренадлежит

смотри, есть два варианта. либо у меня во всех командах свойства surveyId, respondentId и тогда мне надо найти агрегат-рут по этим двум полям. но поскольку он ES, я не могу сделать запрос where surveyId = B, respondentId = A.

либо я делаю заранее команду "создай прохождение опроса" id = X, surveyId = B, respondentId = A, и потом в командах использую id = X. но тогда я не могу быть уверен, что для B, A существует только один такой агрегат-рут.

важный момент, что уже во время прохождения опроса я не могу сначала создать id, потом его где-то запомнить и начать передавать, так как на прохождение выдаётся ссылка с зашитым jwt и пользователь может несколько раз по ней переходить с разных устройств.

а можешь ссылку кинуть, про какое место php-service-bus ты?

а в jwt положить id прохождения нельзя?

Можно, просто это не решает проблему неединственности. То есть мне нужна гарантия, что кол-во прохождений для любой пары будет <= 1. Ну короче вариант uuid5 самый простой, вариант с таблицей более удобный в долгосрочной перспективе.

почему не решает? При проходе по ссылке прохождение уже будет. Неважно сколько переходов по ссылке будет - прохождение будет 1

Ссылки генерируются в разных местах при рассылках разными способами и мне глобально надо, чтобы так или иначе респондент оказывался в том же прохождении. То есть я могу, конечно, спрашивать каждый раз, нет ли у вас там такого id для такой пары. Но это будет дорого

дорого по каким ресурсам?

Надо в базу лазить

Ссылки генерируются в разных местах при рассылках разными способами и мне глобально надо, чтобы так или иначе респондент оказывался в том же прохождении. То есть я могу, конечно, спрашивать каждый раз, нет ли у вас там такого id для такой пары. Но это будет дорого

есть ещё вариант хранить идентификаторы опросов, на которые уже создано прохождение в респонденте и тогда если этот объект будет контролировать создание прохождения - всё должно быть ок 🤔

Да, и плюс это даже другой контекст, не хочется их зря пересекать. Респондент вообще может туда, кстати, не дойти, поэтому ещё плюс не хочется заблаговременно там что-то создавать.

респондент и опрос? Я конечно не знаю что у тебя там, но на первый взгляд это один контекст. Для чего ещё нужен респондент, кроме как для прохождения опроса? Не логиниться же и кофе варить.
Может и не дойти, что тебе с этого? Ну подчистишь если что. И потом - разве бизнесу не интересно кто дошёл, а кто нет?