Recentemente ho letto molto su Event Sourcing nel mio tempo libero.
Capisco che sia per le situazioni (contesti limitati?) dove l'azienda è interessata a come un'entità è arrivata nel suo stato attuale. L'esempio classico è una banca, che non memorizza il saldo corrente, ma una raccolta di debiti e crediti, che mostra come è arrivato il saldo.
Di recente stavo guardando qualche codice. Si prega di consultare il DDL di seguito:
CREATE TABLE Query (ID int IDENTITY, User ID int, Salary int, Deposit int, Term int, value int, primary key (ID))
CREATE TABLE Mortgage (ID int, Description VARCHAR(30), primary key (ID))
CREATE TABLE MortgageQuery (QueryID int foreign key references Query (ID), MortgageID int foreign key Mortgage references (ID), PRIMARY KEY (QueryID, MortgageID))
A una Persona vengono offerte ipoteche sulla base del loro Salario; Depositare; termine; valore di casa ecc. (tra gli altri).
Un utente può eseguire query più volte in questo modo:
INSERT INTO Query (UserID, salary, deposit,term,value)
values (1,30000,35000,30,150000)
INSERT INTO Query (UserID, salary, deposit,term,value)
values (1,30000,38000,30,150000)
INSERT INTO Query (UserID, salary, deposit,term,value)
values (1,30000,25000,30,150000)
INSERT INTO Query (UserID, salary, deposit,term,value)
values (1,30000,35000,25,150000)
INSERT INTO Query (UserID, salary, deposit,term,value)
values (1,30000,38000,25,150000)
INSERT INTO Query (UserID, salary, deposit,term,value)
values (1,30000,25000,25,150000)
Si noti che lo stesso utente (1) ha interrogato più volte con criteri diversi ogni volta. Qui non è come se il termine fosse arrivato a 25 anni o il deposito fosse arrivato a 25.000. Pertanto non credo che questo scenario trarrebbe beneficio da Event Sourcing / Event Store. Ho capito bene?