Nimanui nu-i place sa-l introduca in CV-ul sau, dar cea mai mare parte a activitatii dezvoltatorilor de web este inca de a face operatiuni CRUD pe baze de date. Aceasta este o treaba directa in majoritatea cazurilor, dar, din cand in cand, gestionarea starii modelelor mai complexe poate fi un pic dificila. O tehnica buna care va poate ajuta sa reduceti complexitatea gestionarii starii este sa separati modul in care persistati si sa preluati date din baza de date, asa cum se face prin modelul CQRS. Ceea ce este doar un mod fantezist de a imparti problema in parti mai mici.

Array

O conceptie gresita despre CQRS este ca oamenii o raporteaza imediat la modul in care comunitatea Java si C # a absorbit-o cu finetea intreprinderii lor. Dar nu este singurul mod de a face acest lucru, asa cum a scris Martin Fowler in postarea sa despre CQRS „ In centrul sau se afla notiunea ca puteti utiliza un alt model pentru a actualiza informatiile decat modelul pe care il utilizati pentru a citi informatii. ”

Sourcing-ul de evenimente completeaza CQRS in sensul ca poate avea grija de partea de scriere, asa cum este scris pe CQRS si ES Deep Dive de Microsoft „ Daca capturati modificarile modelului dvs. de scriere ca evenimente, puteti salva toate modificarile dvs.

Array

pur si simplu adaugand acele evenimente in baza de date sau in magazinul de date de pe partea de scriere folosind doar operatii Insert. ”

In primul rand, cea mai valoroasa invatare pe care o iau din aceste tehnici este ideea fluxurilor de evenimente folosite pentru a genera diferite proiectii / interpretari ale datelor sale. Acesta este un concept destul de cool si aduce o multime de posibilitati dezvoltarii de software. O buna analogie pentru procesarea evenimentelor este o prisma in care lumina alba este sparta in culorile sale constitutive.

Array

Deci, acestea sunt cele 3 parti fundamentale cu care ma voi juca:

Obiectivul principal fiind de a genera modele citite din fluxul de evenimente.

CQRS + ES este foarte atragator , ce am putea invata din el?

– Separati citirea si scrierea – OK , in niciun caz, poate exista o diferenta serioasa in ceea ce priveste modul in care cititi si scrieti, ceea ce poate distruge un model de baza de date.

– Avand un flux de evenimente in care evenimentele care pot fi utilizate pentru a crea proiectii ale datelor sale – de asemenea , OK , concept frumos.

– Trebuie sa adopte cadre complete sau sa construiesti nave spatiale pentru a face procesarea evenimentelor – NU se va intampla .

In opinia mea, solutia ideala trebuie sa fie simpla si realizabila cu orice tehnologie aveti in prezent. Schimbarea mentalitatii de la modelul de date conventional la programarea bazata pe evenimente este deja o mare schimbare.

Cere prea mult? Poate, dar care este problema cand te joci putin cu el si te distrezi?

JS / Flux / Redux ne-au invatat toate lucrurile bune despre gestionarea statului, sunt destul de sigur ca il putem adauga la mix si simplificam procesarea evenimentelor in continuare, aducandu-l din domeniul ingineriei. Asa s- a nascut Binocularul , un mic proiect care se joaca cu aceste concepte. Acesta combina modelul observator cu reductoare pentru a crea ceva diferit.

De ce Binocular ca nume de proiect?

La fel ca CQRS, viziunea binoculara se intampla atunci cand doua imagini separate de doi ochi sunt combinate cu succes intr-o singura imagine din creier. CQRS are doi ochi: ochii de citit si de scris ????.

Care este misiunea?

  • Faceti-o in PHP, deoarece acesta este limbajul pe care il iubesc.
  • Scrieti evenimente intr-un mod ieftin, imuabil, adaugati doar mod.
  • Utilizati proiectiile pentru a citi din fluxul de evenimente si a calcula starea modelelor citite.
  • Poti schimba modul in care sunt procesate evenimentele fara a sparge nimic.

Ingredientele

  • Eveniment : reprezinta ceva ce s-a intamplat deja, are o proprietate ID de radacina pe care proiectiile o vor folosi pentru a agrega evenimentele si are, de asemenea, actiuni care trebuie aplicate de catre reductori. Sunt actiuni la plural, deoarece o actiune poate avea mai multe versiuni.
  • Actiune : are un nume si o versiune, face maparea intre reductoare si evenimente.
  • Proiectie : in calitate de consumatori, ei interpreteaza si extrag informatii din fluxul de evenimente. Are reductoare care vor schimba starea modelelor citite. Pentru simplitate, proiectiile de dragoste sunt 1–1 cu modelele citite.
  • Reductoare : practic o serie de apeluri versibile care traiesc in proiectii. Deoarece evenimentele sunt versionate, reductoarele sunt si versionate, este o forma de mapare. Daca se creeaza o noua versiune a evenimentului, trebuie sa fie creata si o noua versiune de reducere pentru a procesa modificarile.
  • Depozit de evenimente : persista si recupereaza evenimente.
  • Read Model Repository : persista si recupereaza modelele citite.

Justificari

Nu exista nicio legatura intre evenimente si proiectii

Binocularul nu ofera o modalitate de „cablare” a proiectiilor si evenimentelor, in schimb clasa de proiectie de baza furnizata are un depozit de evenimente ca dependenta, unde poate prelua si reda evenimente pentru a calcula starea. Aceasta a fost o decizie constienta de a nu reinventa roata, deoarece majoritatea cadrelor PHP ofera o implementare a modelului de observator, folositi doar ceea ce ofera cadrul. O modalitate usoara de a combina binocularul cu modelul de observator este de a persista evenimentele inainte de a fi declansate / asteptate si de a utiliza proiectii in clasa ascultator pentru a calcula starea modelului sau de citire.

Motivul pentru relatia 1-1 dintre modelele citite si proiectii

Fortarea acestora sa fie 1-1 face mai usor sa rationam in detrimentul unei flexibilitati mai mici. O proiectie ar trebui sa calculeze starea unui singur model citit.

Multumesc pentru lectura! ❤

PS

ARTICOLE SIMILAREDE LA ACELAȘI AUTOR