CQRS senza utilizzare altri modelli

Question

CQRS senza utilizzare altri modelli

#1 da (5 voti)

7

Vorrei spiegare CQRS al mio team di sviluppatori. Non riesco proprio a capire come spiegarlo nel modo più semplice in modo che possano implementare il modello rapidamente senza altri framework. Ho letto molte risorse, inclusi video e articoli, ma non trovo il modo di implementare CQRS senza utilizzare altri modelli come un bus di servizio, un modello di sourcing di eventi, una progettazione basata sul dominio. Conosco lo scopo di questi pattern, ma per il primo passo, non voglio che pensino al CQRS e questi pattern devono essere legati insieme.

La mia prima idea è di dire che CQRS riguarda la separazione tra la parte letta e la parte di scrittura. La parte di lettura è composta solo dal progetto UI e dal progetto DAL. Quindi la parte di scrittura è composta da un'architettura a più livelli tipica: UI / BLL / DAL. Quindi, il CQRS dice che dobbiamo avere anche due datastore? Che dire della nozione di comandi che rivelano l'intenzione dell'utente, è anche qualcosa che fa parte di CQRS o DDD?

In pratica, come implementare CQRS senza utilizzare altri pattern. Ammetto anche che non è chiaro nella mia mente perché ho lavorato con NCQRS / DDD / Event Sourcing / ServiceBus nel mio progetto personale.

design-patterns cqrs

posta John Smith 19.11.2011 - 22:06

fonte

1 risposta

Leggi altre domande sui tag design-patterns cqrs

Config Class / Struct: Pattern o Anti-Pattern? Alternative? Effettuare il passaggio da MySQL a PostgreSQL?

score 5 · Accepted Answer

Ci sono molti modi per farlo. Conosci meglio la tua squadra. È meglio chiedersi a quale livello di astrazione devi parlare per farli capire.

Cqrs si occupa davvero di separare la logica di lettura dalla logica di scrittura. Questo è meglio spiegato confrontandolo con l'architettura a più livelli di oggi come promosso dai venditori di database (la sezione video su link fa un buon lavoro in questo), soprattutto perché le persone possono relazionarsi ad esso e vedere come le modifiche che proponi rientrano in quell'architettura. Potresti semplicemente fermarti all'argomento che allo scopo di leggere i dati non c'è bisogno di saltare attraverso tutti i cerchi (della logica di scrittura). Non c'è bisogno di andare oltre (negozi separati, concetti di ddd, messaggistica, bus di servizio, ecc.). Detto questo, c'è molto più valore da guadagnare, sia dal punto di vista tecnico che funzionale, se si prosegue ulteriormente. Ma ancora, 1 passo alla volta. Ricorda, le persone in generale non amano molto il cambiamento (anche se è un buon cambiamento). C'è molto valore nella progenie di cqrs, ma richiede un giudizio attento e un giudizio se si adatta alla tua squadra (e alla sua maturità). A volte è meglio crescere insieme piuttosto che trascinare le persone in qualcosa. Inoltre, non dimenticare che anche la gestione non deve essere ignorata.