CQRS in domini collaborativi

Question

CQRS in domini collaborativi

#1 da (3 voti)
#2 da (3 voti)

6

Sto leggendo questo articolo su CQRS e quando si tratta di decidere dove per usarlo, il seguente non mi è davvero venuto in mente:

Collaborative domains where multiple operations are performed in parallel on the same data. CQRS allows you to define commands with enough granularity to minimize merge conflicts at the domain level (any conflicts that do arise can be merged by the command), even when updating what appears to be the same type of data.

Alcuni possono elaborarlo con un possibile esempio. Penso che ciò significhi che è possibile emettere più comandi di scrittura granulari per aggiornare parti più piccole di una tabella, una riga, ecc. Per ridurre al minimo la sovrapposizione, quindi bloccare su aree più piccole quindi prestazioni migliori. Ma come non è possibile con le operazioni CRUD di tutti i giorni?

architecture cqrs

posta Tarik 28.01.2018 - 08:04

fonte

2 risposte

Leggi altre domande sui tag architecture cqrs

Come strutturare un progetto di cipolla Come evitare o amalgamare minuscole storie di utenti in late project?

score 3 · Answer 1

Sì, puoi anche avere comandi granulari con CRUD. Quel paragrafo non riguarda le differenze tra CRUD e CQRS, ma dove potresti usare CQRS.

Per capire le differenze dovresti leggere l'intero articolo, forse più di una volta.

Per quanto riguarda i comandi, una differenza tra le due architetture è che, in CQRS il comando ha anche un significato dal punto di vista del business, porta anche l' intento , avendo un nome dal linguaggio onnipresente . In CRUD l'intento, il perché manca; potrebbe essere derivato da quali campi sono modificati ma è oscurato.

score 3 · Answer 2

Mi piace di più il post su CQRS di Udi Dahan, e prendo un esempio da lì:

Let’s say we have a customer service representative who is one the phone with a customer. This user is looking at the customer’s details on the screen and wants to make them a ‘preferred’ customer, as well as modifying their address, changing their title from Ms to Mrs, changing their last name, and indicating that they’re now married. What the user doesn’t know is that after opening the screen, an event arrived from the billing department indicating that this same customer doesn’t pay their bills – they’re delinquent. At this point, our user submits their changes.

Should we accept their changes?

Well, we should accept some of them, but not the change to ‘preferred’, since the customer is delinquent.

E, riguardo alla tua domanda

But how is that not possible with everyday CRUD operations?

Non c'è nulla come comando in CRUD per definizione. In CRUD abbiamo solo, uhm, CRUD: creare, leggere, aggiornare ed eliminare. Ecco come appare l'imitazione del comando con CRUD (di nuovo, è un estratto dal post di Udi Dahan):

But writing those kinds of checks is a pain – we need to do a diff on the data, infer what the changes mean, which ones are related to each other (name change, title change) and which are separate, identify which data to check against – not just compared to the data the user retrieved, but compared to the current state in the database, and then reject or accept.

Non si tratta solo di prestazioni. Si tratta anche di migliorare l'esperienza utente complessiva. Se il comando è valido, ovvero intervalli di date, e-mail, ecc. (Che possono essere assicurati sul lato client), il server non deve restituire errori la maggior parte del tempo. È in grado di gestire eventuali incoerenze causate da comandi paralleli in modo asincrono e di notificare un client con, ad esempio, un'e-mail. Ciò è diventato possibile, come ha detto anche Constantin Galbenu, perché i comandi catturano un intento imprenditoriale. In caso di " race condition " puoi chiedere al tuo esperto di dominio cosa fare e lui sarà in grado di rispondere.