Pattern per cross-application / servizio aggregatore di eventi / messaggistica

1

Abbiamo un mucchio di spaghetti di un'applicazione a cui sono stato affidato il compito di ricostruire. Voglio davvero rendere il nuovo codice molto più flessibile e anche più distribuito.

A livello base l'applicazione raccoglie i dati dall'hardware, esegue alcune azioni di controllo, visualizza i dati e consente all'utente di inviare le impostazioni all'hardware.

Non c'era alcuna separazione, il codice era specifico dell'hardware, nessun livello di accesso ai dati / disconnessione tra dati, backend, controllo e infine interfaccia utente. È stato un pasticcio orribile quando abbiamo avuto un cambio di hardware, e tutto doveva essere rielaborato. Era anche una singola applicazione su un singolo computer, ma abbiamo bisogno che sia più modulare. Forse un server raccoglie dati e prende decisioni di controllo locali, ecc. E quando ha un link, lo carica in un database centrale.

Sto cercando di creare alcuni schemi di architettura / design che possano aiutare in questo e ho visto che l'aggregatore di eventi è venuto fuori molto. Tuttavia, sembra principalmente rivolto al lato dell'interfaccia utente, mentre sto pensando a una messaggistica cross-service / application.

Questo suona come un design sensato? Suona come un modello di design là fuori? Non voglio re-inventare la ruota.

Il principio principale degli agitatori di eventi, che la fonte e il consumatore degli eventi non conoscono l'un l'altro sembra che potrebbe essere difficile da raggiungere quando non condividono un'applicazione.

    
posta Joe 14.09.2016 - 13:58
fonte

1 risposta

1

Penso che tu sia sulla strada giusta con Aggregatore di eventi .

Considera l'alternativa che è il pattern Observer e ti rendi conto che ci sono più fonti di eventi hardware che devi avere una logica di gestione per osservare e prendere decisioni. Martin Fowler fa un lavoro migliore di quello che faccio per spiegare i vantaggi di Event Aggregator qui.

Considera anche tutti gli importanti attributi di qualità del tuo sistema e consenti agli attributi più importanti di guidare le tue decisioni architettoniche qui.

  • Modularità
  • L'interoperabilità
  • Composability
  • Maintainability

Un'architettura basata sui messaggi che utilizza il pattern Aggregatore di eventi può indirizzare il consolidamento dei messaggi creati dai componenti e fare una serie di cose con questo.

  • Un'opzione è che se questi dati devono essere persistenti, ha senso trasformare il messaggio in un formato dati comune e persistere in un archivio dati / file / database. Un altro componente del servizio può leggere i dati dal database per la segnalazione e lo stato
  • Un'altra opzione è che il componente aggregatore può invece pubblicare un messaggio in un argomento in un formato comune e più componenti del destinatario che sottoscrivono tale argomento riceveranno il messaggio e scelgono di archiviare potenzialmente i dati nel proprio negozio o fare qualcos'altro con il dati interamente in tempo reale. Informazioni sugli argomenti link

Vedo i componenti del software di astrazione dell'hardware che inviano messaggi di dati non elaborati a una coda remota. Questi messaggi trasmettono tutti a una coda locale che il componente Aggregator ascolterà per i messaggi in arrivo. Può quindi trasformare i dati in un formato comune e pubblicare un messaggio su un argomento o salvare i dati in un database. Questo aggregatore può anche gestire opzionalmente l'invio di messaggi nell'ordine inverso tramite diverse code di messsage a vari componenti di astrazione hardware per le modifiche di configurazione. Potresti anche avere un componente e un processo Aggregator separati per gestire questo caso d'uso.

Ora puoi creare servizi sul tuo database per le richieste di lettura dei dati e contro una coda di messaggi per le modifiche alla configurazione in entrata.

Questo ti offre separazione delle preoccupazioni, modularità più semplice quando i componenti del software sono in piedi, facilità di manutenzione e astrazione dai cambiamenti hardware e maggiore flessibilità sul lato GUI per avere più tipi di interfacce utente (applicazione Desktop, applicazione web, mobile, ecc ...).

    
risposta data 14.09.2016 - 15:08
fonte

Leggi altre domande sui tag