CQRS / Event Sourcing - ожидается ли получение Aggregate Id от пользователя / запроса?

Question

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

Я решил смоделировать склад в качестве моего совокупного корня в области доставки / инвентаризации, где количество складов, как правило, довольно постоянное (т.е. компания не будет добавлять склады слишком часто).

Я столкнулся с вопросом о том, как установить мой aggregateId, который должен соответствовать хранилищу, на моем сервере.Большинство примеров, которые я видел, включая этот , показывают идентификатор агрегата, который генерируется на стороне сервера, когда создается новый агрегат (в моем случае хранилище), а затем передается в запросе команды при обращении к нему.агрегат для последующих команд.

Вы бы сказали, что это правильный подход?C a Я ожидаю, что пользователь будет знать и передавать агрегированные идентификаторы при выдаче команд? Я понимаю, что это, вероятно, зависит от домена и также может быть выбором UI / UX, просто интересно, что сделали другие.Для меня было бы больше смысла, если бы число моих исходных агрегатов было более частым, например, с закладками на еду или корзинами для покупок.

Спасибо!

Answer 1

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

Можно ли ожидать, что пользователь будет знать и передавать агрегированные идентификаторы при выдаче команд?

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

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

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

Клиент обычно знает, что такое идентификатор, потому что он только что получил его во время предыдущего запроса.

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

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

Возможно, вы захотите ознакомиться с 10-летней ретроспективой Грега Янга, которая включает обсуждение складские системы .TL; DR - во многих случаях сообщения, поступающие от операторов, являются событиями , а не командами.

Answer 2

Вы бы сказали, что это правильный подход?

Вы спрашиваете, представляет ли один из примеров Greg Young's Event Sourcing правильный подход ... Учитывая, что комбинация CQRS иEvent Sourcing был по сути (заново) изобретен Грегом, я бы сказал, что есть довольно хорошие шансы на это.

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

Можно ли ожидать, что пользователь будет знать и передавать агрегированные идентификаторы при выдаче команд?

Нет, а вы?в частности, нельзя ожидать, что пользователь узнает GUID своих активов.Что вы можете сделать, это представить пользователю список его или ее активов.С каждым элементом в списке будет связан GUID, но, возможно, нет необходимости отображать этот идентификатор в пользовательском интерфейсе.Это просто данные, которые базовый объект пользовательского интерфейса хранит внутри.

В некоторых случаях пользователям необходимо знать идентификатор некоторых своих активов (например, если это связано с поддержкой по телефону).В этом случае вы можете добавить API поиска для решения этой проблемы .