Состояние изменения событий в CQRS

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

Итак, предположим, что пользователю нужно изменить свой номер мобильного телефона, для этого у нас может быть команда как: ChangedUserMobileNumber

удерживая новый номер. Домен, ответственный за обработку команды, выполнит изменение агрегата и опубликует событие: UserMobilePhoneChanged.

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

Домен 1 получает команду на обновление номера мобильного телефона, номер обновляется, и одно событие публикуется, также, поскольку событие не может содержать данные, обработчик команд в Домене 1 выдает еще одну команду, которая отправляется в Домен 2. Подписчик этого события тоже живет в Домене 2, тогда у нас есть сага для обработки как события, так и команды.

Что касается реализации, мы используем NServiceBus, поэтому у нас есть эта сага для обработки этих сообщений, и в ней у нас есть эта строка кода, где поле entity.IsMobilePhoneUpdated, хранящееся в сущности саги, изменяется при обработке события.

bool isReady = (entity.IsMobilePhoneUpdated && entity.MobilePhoneNumber! = null);

Фактически сага запускается как командой, так и событием, возникшим в Домене 1, и до тех пор, пока это условие не будет выполнено, сага сохраняется.

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

Спасибо


events cqrs saga
person MeTitus    schedule 08.09.2012    source источник

Ответы (2)


arrow_upward
3
arrow_downward

Я не уверен, что событие UserMobilePhoneChanged может быть полезно каким-либо образом, если оно не содержит новый номер телефона. Пользователь просит изменить номер, событие выстреливает, что у него есть. Должно быть действительно очень просто. Почему ваш архитектор говорит, что события не должны содержать никакой информации?

person Sebastian Good    schedule 08.09.2012
comment
Я правда не знаю. Мне сказали, что архитектор убежден в том, что у событий не должно быть данных, и, поскольку я был архитектором программного обеспечения до прихода в эту компанию, я не знаю, что спрашивать архитектора, почему у него такое убеждение, потому что у меня могут возникнуть проблемы. Я присоединился к этой компании пару месяцев назад, поэтому я действительно не хочу создавать здесь проблемы, но чем больше я смотрю на их реализацию SOA с использованием NServiceBus, тем больше я понимаю, что они поняли большую часть основ неправильно. Я просто хотел получить информацию об этом, я работал с SOA CQRS раньше, но я думал, что мне не хватает чего-то нового. - person MeTitus; 08.09.2012
comment
Вся система построена на этой концепции. Всякий раз, когда происходит изменение, выполняемое командой, создается событие, которое не передает состояние, и новая команда домена также выдается с измененными данными. Сумасшедшие вещи, и чем больше я смотрю, тем больше понимаю, что эти ребята вошли в SOA с CQRS, не зная, что это такое. - person MeTitus; 08.09.2012

arrow_upward
1
arrow_downward

В первой системе, основанной на событиях, которые я разработал, события также не имели данных. Я также соблюдал это правило. В то время это казалось разумным решением. Через некоторое время я понял, что это глупо, и я пытался найти из-за этого множество обходных путей. Также это вызвало множество запросов от подписчиков событий, даже для тривиальных данных. У меня не было проблем с изменением этого «правила» после того, как я понял, что делаю это неправильно.

События должны иметь все данные, необходимые для того, чтобы сделать их значимыми. Кроме того, они должны иметь только те данные, которые имеют смысл для этого события. (Нет смысла указывать адрес пользователя в сообщении ChangePhoneNumber)

Если ваш архитектор наложит такое ограничение, разработать систему CQRS будет непросто. Как обновляются считанные модели? Поскольку у событий нет данных, вы либо запрашиваете что-то, чтобы получить данные (сторона записи?), Либо находите способ отправки команды в модель чтения (тогда в чем смысл публикации событий?). Чтобы решить вашу проблему, вы должны попытаться провести профессиональное обсуждение с этим архитектором, желательно с участием других технических руководителей и, никого не обижая, попытаться заставить его ослабить это ограничение.

В качестве аргумента вы можете использовать Event Sourcing. Источник событий дополняет CQRS и не имеет смысла без событий, у которых есть данные. Более того, при использовании источника событий единственные данные, которые у вас есть, - это данные, хранящиеся в событиях. Даже если вы на самом деле не реализуете источник событий, вы можете использовать его существование как причину, по которой события имеют данные.

Нет смысла искать техническое решение проблемы людей.

person Iulian Margarintescu    schedule 09.09.2012
comment
Привет, Юлиан, но вы, должно быть, читали откуда-то, что это правильный способ сделать это, не так ли? Я уверен, что наш архитектор достаточно умен, но, возможно, он просто прочитал какой-то документ, в котором утверждается, что это реальный способ практиковать CQRS. - person MeTitus; 10.09.2012
comment
Читайте модели! У нас их тоже нет, у нас есть запросы и команды, но та же модель для чтения / записи, и мы также не используем никаких агрегированных корней, это все беспорядок, но, честно говоря, некоторые из этих проблем уже здесь, когда архитектор присоединился к компании, так мне сказали. - person MeTitus; 10.09.2012
comment
Вы совершенно правы, и иногда мне кажется настолько странным, что люди следуют всем этим концепциям так слепо, не задумываясь на время, легко понять, что все это неправильно, но опять же, это не мое звоните, и в конце концов меня уже привлекли внимание, потому что я задавал слишком много вопросов. Хуже всего то, что, даже зная, что что-то не так, вы должны продолжать делать это неправильно. Большое спасибо за ваш вклад. - person MeTitus; 10.09.2012
comment
Если вам не нравится то, что вы задаете много вопросов, я настоятельно рекомендую вам подумать о поиске другой работы :). Это одно из самых важных качеств, которые я ищу в разработчиках, с которыми я работаю. - person Iulian Margarintescu; 11.09.2012
comment
В прошлом я также наставлял новых парней, и это качество, которое я тоже очень ценил, мы знаем, что когда люди все время просто «да», не задавая вопросов, что-то не так. Что касается поиска другой работы, мне очень нравится эта компания, но с ней действительно сложно справляться с одними и теми же вещами, например, делать что-то неправильно, когда вы знаете, что они ошибаются. Мне пришлось переехать, чтобы получить эту работу, и мне также пришлось перейти на должность архитектора программного обеспечения к старшему разработчику, я просто думал, что переезд будет проще. - person MeTitus; 11.09.2012