Събития, променящи състоянието си в 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