Lettura del risultato del comando con il modello di comando

1

Attualmente sto studiando lo sviluppo di un nuovo sistema che utilizza l'architettura esagonale e il pattern di comando facilitato da un commandbus come il tattico (è un sistema PHP).

Ora mi piace molto l'idea di commandpattern ma quello che non ho ancora è come recuperare il risultato effettivo di ciò che il comando ha fatto.

Diciamo che emetto un comando RegisterPatient con i seguenti campi:

  • Nome
  • Indirizzo
  • nascita

etc

Il comando è stato riempito con dati provenienti da un'interfaccia HTTP, dati al commandhandler ed eseguiti. Se tutto va bene, creerà un oggetto Patient e lo conserverà nel database. Ma commandPattern non mi permette di restituire l'oggetto Patient costruito, in parte perché c'è la possibilità di aggiungere il middleware prima e dopo, quindi dovrebbe restituire il comando stesso.

Ho capito che esiste un valore nella separazione tra le applicazioni di lettura e scrittura, ma in pratica, come posso ottenere i dati dal datastore dopo che il comando è stato eseguito o leggere le query in generale? Non sarebbe saggio iniettare la RepositoryInterface per un determinato modello direttamente nel mio controller se volessi generare una vista indice per esempio?

Quali sono i modi pratici per gestire gli errori con i comandi?

Aiuto molto apprezzato.

    
posta shokora 13.06.2016 - 14:07
fonte

2 risposte

0

Alla mia domanda è stata data una risposta in questo articolo: link

The command bus has no return value. So instead of waiting for the ID to come back from the database, the ID should be one of the values of the command object. If you then hand it over to the command bus, and nothing fails, you can safely assume that an entity with the given ID has been created (usually an ID is a UUID, instead of an auto-incremented ID from the database).

    
risposta data 21.06.2016 - 13:06
fonte
1

In questo esempio del modello di comando , la restituzione di un valore viene gestita con un callback. Immagino che un futuro o una promessa funzionerebbero altrettanto bene.

Il disaccoppiamento del tipo restituito non è menzionato nell'esempio; nei sistemi che ho visto che sono simili a questo in cui si sottoscrive un evento (l'equivalente morale di un callback "generico"), si restituirebbe un oggetto nullo e quindi lo si invierà al tipo di reso previsto.

Gestire gli errori sarebbe una semplice questione di fornire un codice di errore o una condizione nell'oggetto restituito.

    
risposta data 13.06.2016 - 15:53
fonte

Leggi altre domande sui tag