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.