Se abbiamo detto che sincrono e asincrono sono la stessa cosa, su quale base possiamo ritenere affidabile il modello in lettura? Abbiamo però anche detto che il modello in lettura è la verità per l’utente, o in maniera più generica, per il chiamante.

Ripartiamo da dove ci siamo fermati:

  1. chiedere al sistema l’elenco di tutti i clienti insolventi;
  2. se vi sono clienti involventi;
  3. avviare una pratica di recupero crediti con tutti i clienti insolventi;

Quale dovrebbe essere l’approccio?

  1. chiedere al sistema l’elenco di tutti i clienti insolventi;
  2. se vi sono clienti involventi;
  3. avviare una pratica di recupero crediti per ognuno dei clienti che risultano insolventi;

La prima considerazione da fare è che un comando come:

{
    commandType: ‘avviaPraticaRecuperoCrediti’,
    condition: ‘per tutti i clienti insolventi’
}

è un po’ come il matrimonio più famoso d’Italia, non s’ha da fare. Quello che devo eseguire come comando è:

{
    commandType: ‘avviaPraticaRecuperoCrediti’,
    clientIds: [123, 567, 234]
}

fondamentale quindi è essere molto precisi su quello che sto chiedendo. La domanda adesso però dovrebbe essere un’altra…

Sono abbastanza preciso?

Non direi. O meglio, non è detto. Immaginiamo un altro scenario:

  1. Chiedo al sistema l’elenco dei clienti che non hanno eseguito ordini negli x mesi;
  2. Mando una mail con una promozione a ognuno di quei clienti;

Quello che potrebbe succedere, e sono sicuro che vi vengono in mento un sacco di altri scenari, è che nel frattempo uno di quei clienti fa un ordine e non ha molto senso mandargli la promozione, sia dal punto di vista economico che dal punto di vista d’immagine (quanto volte vi ha chiamato Vodafone offrendovi una promozione per diventare clienti…quando voi siate già clienti…? ecco…).

Nel primo esempio, il recupero crediti, mi aspetto che l’infrastruttura di validazione non permetta di mandare in protesto un cliente che ha senso protestare, quindi il problema non si pone, ma nello scenario qui sopra è che non c’è una regola di business e l’invio di una promozione potrebbe essere a discrezione dell’operatore, il problema è che l’operatore ha preso una decisione su dati non più veri.

Molte verità

In un sistema non consistente la verità è in funzione del tempo, il tempo quindi è una variabile fondamentale per capire quale verità stiamo guardando:

{
    commandType: ‘inviaPromozione’,
    clients: [{
        id: 123,
        version: 12
    }, {
        id: 789,
        version: 3
    }]
}

Quanto è semplice ed elegante? Mi sto limitando a dire che sto basando le mie decisioni su una verità in un certo momento t, la versione. A questo punto cosa ci vieta di aggiustare il nostro repository in questo modo:

interface IRepository<T>
{
   void Add(T entity);
   T GetById(int Id);
   T GetById(int Id, int version);
   void CommitChanges();
}

…e decidere che se la version passata non è la più recente ci becchiamo una sonora eccezione (o quello che preferite nel vostro contesto)?

Posso quindi fidarmi del modello in lettura? ciecamente :-)

.m