CQRS - допустимый вариант использования командного поиска?

Question

Я работаю с системой CQRS, которая сохраняет команды (с полезными нагрузками и флагом успеха).

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

Я думаю, это означает, что мне придется хранить идентификатор команды в какой-либо таблице / представлении на стороне чтения, когда пользователь вводит команду. Это выглядит примерно так:

1. пользователь вводит данные формы
2. пользователь выдает AttachToCollectionCommand, который сохраняет команду в препроцессоре
3. В обработчике вводятся входные данныедля некоторого сервиса, затем сохраняет output и collectionId в некоторой таблице A.
4. Все еще в обработчике идентификатор команды (вместе с collecitonId) сохраняется в другой таблице B.
5. постпроцессор обновляет флаг успешного выполнения команды.

Теперь, когда пользователь открывает эту коллекцию, мы можем загрузить входные данные (из B) и выходные данные (из A) для каждой записи этой коллекции.

Мой вопрос, имеет ли смысл даже запрашивать в этом хранилище команд его полезную нагрузку для заполнения входных данных, используемых для определенного члена коллекции? Это допустимый вариант использования для этого хранилища команд? Я вижу проблему: если входные данные в конечном итоге изменятся, это затруднит обратную совместимость.

Спасибо

Answer 1

В универсальном CQRS и Event Sourcing нет необходимости в хранении команд, только в хранилище событий, но ничто не мешает этому. Таким образом, срок действия варианта использования зависит от вашего бизнеса. Он действителен, если вы считаете, что он действителен.

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

Я беспокоюсь о том, чтобы пойти по этому пути, ожидая от пользователя. V1 системы воспроизведения команд будет много работы, но не очень сложно. Пользователи будут любить его и хотят добавлять функции. Затем появляется V2, и вы должны поддерживать не только механизм воспроизведения команд, но и добавить механизм преобразования команд. Это много хрупких операторов if-then для перемещения данных и манипулирования ими. Затем приходит V3, и вы хотите отказаться от всего этого, потому что это такая трата времени, но пользователи не позволят вам.

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

Воспроизведение команд - хорошая идея для QA многократно воспроизводить сценарии во время тестирования, но разве это не просто интеграционный тест? Значение QAs входит в предварительное тестирование, а не в повторное тестирование одного и того же.

Извините за напыщенную речь. Если пользователи хотят эту функцию с учетом требований разработчика и времени обслуживания, использование сохраненных команд является правильным подходом. Я бы просто позаботился о том, чтобы запрашивающий знал, сколько требуется обслуживания для каждой версии, чтобы поддерживать работу. В противном случае вы отбрасываете все эти усилия.