Mi sembra che gli hash di Ruby siano una buona opzione per implementare gli oggetti Data Transfer che i servizi applicativi ricevono dal codice client come comandi e richieste di query.
Per le risposte al Servizio applicazioni, forse un oggetto risposta con successo / fallimento e una proprietà risultato contenente i dati come hash.
Pensi che questa sia un'implementazione praticabile o un anti-pattern?
Do you think this is a viable implementation or an anti-pattern?
Utilizzare schemi deboli per i messaggi è una buona idea quando il consumatore e il fornitore si evolvono su diverse scale temporali. C'è molto materiale buono là fuori se vuoi imparare in profondità; Il versioning in un sistema di approvvigionamento di eventi di Greg Young è un punto di partenza avanzato.
Per maggiore chiarezza, potresti fare bene a tenere separate le preoccupazioni nascondendo il modello di dati di hash dietro un'astrazione di ciò che l'hash dovrebbe rappresentare in questo contesto.
Per un formato di serializzazione ... forse. Durante l'effettivo trasferimento , non hai un "hash", solo una sequenza di byte. Quindi è necessario riflettere sul fatto che la sequenza di byte soddisfi le proprie esigenze: è abbastanza piccola, ha errori di correzione, è sufficientemente standardizzata per essere compresa da tutte le implementazioni pertinenti degli endpoint e così via.
Naturalmente, la buona notizia è che se mantieni le tue preoccupazioni correttamente separate, puoi scambiare le diverse rappresentazioni per il trasporto senza disturbare il resto della tua app.
Leggi altre domande sui tag domain-driven-design design-patterns services ruby dto