Moeten commando's asynchroon zijn in CQRS?

Uit wat ik heb gelezen, hebben CQRS-ontwerpen betrekking op asynchrone opdrachten waarbij opdrachten in een wachtrij worden geplaatst. De gebruiker gaat ervan uit dat alles goed is en de gebruikersinterface peilt of via een timer wat feedback krijgt als alles werkt of niet.

Hoe zou dit werken als ik een gebruikersinterface had waarin ik mappen in een boom sleep? Ik zou kunnen dat één gebruiker een map verwijdert terwijl een andere gebruiker er een map naartoe sleept (om er een submap van te maken).

Dus vanuit de gebruikersinterface kon ik laten zien dat het slepen heeft plaatsgevonden en vervolgens in een timercontrole om te zien of mijn leesmodel is bijgewerkt (dwz controleer of de bovenliggende map van de gesleepte map correct is en ik weet dat het heeft gewerkt ).

Als de gebruiker een aantal sleepbewerkingen heeft gedaan, zou ik een lijst van deze bewerkingen in de gebruikersinterface moeten bewaren en het leesarchief moeten controleren (alle geslaagde opdrachten uit de lijst verwijderen).

Er zijn misschien betere manieren om dit te doen.

Het lijkt gewoon veel werk in de gebruikersinterface en meer vatbaar voor fouten, terwijl als ik gewoon een synchroon commando voer en als alles in orde is, ik verder ga naar mijn volgende operatie.

6

2 antwoord

Hoewel u synchrone opdrachten kunt gebruiken, wordt het probleem dat u beschrijft geen minder probleem; het betekent alleen iets anders gedrag bij het melden van de gebruiker.

Het ding om te realiseren over commando's is dat ze kunnen worden geweigerd door de domeinobjecten. Wat dat in dit geval zou kunnen betekenen, is dat de eerste gebruiker wijzigingen aanbrengt en dat de wijzigingen die de tweede gebruiker aanbrengt, mogelijk worden geweigerd omdat ze verwijzen naar een ongeldige status.

Als je de huidige status van het systeem aan alle gebruikers wilt presenteren, moet je ui toch al het werk doen waar je je zorgen over maakt; dat is helemaal niet uniek voor CQRS.

5
toegevoegd
"Het streven om gebruikers zo snel mogelijk te informeren of hun acties slagen of niet" is geen universele vereiste waaraan elk systeem moet voldoen. Als de huidige status van de toepassing van cruciaal belang is voor het bepalen van de acties die beschikbaar zijn voor de gebruiker, dan zijn asynchrone opdrachten waarschijnlijk niet de beste ontwerpbeslissing, maar dat betekent niet dat het gebruik van synchrone opdrachten een magische opsomming is die ervoor zorgt dat de status niet verandert tussen opdrachten van één gebruiker .
toegevoegd de auteur arootbeer, de bron
Bedankt voor het antwoord.
toegevoegd de auteur JD., de bron
Ik zie dit meer als een poging om gebruikers zo snel mogelijk te informeren of hun acties slagen of niet. En dus is het naar mijn mening slecht vanuit het oogpunt van UI-bruikbaarheid, zodat gebruikers enkele mappen later moeiteloos mappen kunnen rondslepen om "de server op te roepen" en te weten komen dat al deze acties zijn geweigerd - ik denk dat de gebruiker moet worden geïnformeerd meteen. Hetzelfde geldt voor problemen met het opslaan van gegevens (denk aan validatie!) En de meeste, zo niet alle andere foutcondities.
toegevoegd de auteur Dav, de bron

Je kunt heel goed synchrone commando's gebruiken. Asynchrone opdrachten zijn niet vereist voor CQRS.

3
toegevoegd