Come modellare i processi paralleli (in un Contesto Limitato) con lo stesso archivio dati?

1

La situazione. Diciamo che un processo in background mette le cose in contenitori di dati. Funziona tutto il tempo, osserva gli eventi di sistema e popola i dati di conseguenza.

L'utente può avviare un'applicazione del pannello di controllo. Con questa applicazione, l'utente può definire nuovi contenitori, rinominare o eliminare quelli vecchi. Il pannello è separato dal processo reale del cavallo di battaglia per non prenderlo accidentalmente quando si blocca.

Per l'esempio, supponiamo che il processo in background aumenti di un contatore per ogni contenitore di 1 ogni minuto. È un contatore di vita. Ha bisogno di sapere dei contenitori. È l'unico processo che modifica i contatori, però.

Il pannello di controllo dovrebbe visualizzare un elenco di contenitori e il conteggio corrente. Dovrebbe aggiornare un conteggio visualizzato quando necessario (ad esempio quando il contatore è cambiato nel frattempo). Ha bisogno di leggere i dati ma non di scriverli, tranne forse per la modifica del set di contenitori.

La domanda. Entrambi i processi operano su un dominio simile. Entrambi hanno bisogno di sapere su contenitori e conteggi. Fanno solo cose diverse con loro. Ora, come modellerai questo in termini di DDD?

Ho riflettuto sul fatto che fossero contesti limitati diversi, ma dal momento che il dominio sembra essere esattamente lo stesso, non c'è alcun indicatore che ciò sia necessario. La separazione tra entrambi è puramente tecnica. Forse fare qualche tipo di RPC?

Come dovrebbero i processi condividere i dati? Se il pannello di controllo diventa un processo di sola lettura, accedere allo stesso archivio dati in cui il processo in background scrive e delegare la creazione del contenitore al processo in background in modo che la scrittura sia unificata? (È già presente questo CQRS?)

    
posta ctietze 23.01.2015 - 17:03
fonte

1 risposta

2

Utilizza un framework pub / sub come nServiceBus. Il pannello di controllo può iscriversi per aggiornare gli eventi sul modello di dominio. Il processo in background emetterà gli eventi di aggiornamento. Quando il pannello di controllo si avvia per la prima volta, invierà un comando al processo in background per dirgli di inviare tutte le informazioni di cui ha bisogno.

I messaggi conterranno oggetti di dominio serializzati. La struttura si occupa di assicurarsi che arrivino. Ad esempio con nServicebus è possibile utilizzare MSMQ ed essere su macchine separate (ovviamente o la stessa, ma qui presumo che il pannello di controllo sia in esecuzione su un server web e il processo di aggiornamento sia in esecuzione su un server app).

Ora per gli aggiornamenti, il pannello di controllo può inviare comandi tramite il bus al processo di aggiornamento, riflettendo l'aggiornamento desiderato. Stessa idea, serializza qualche informazione e mettila sul bus. L'interfaccia utente può quindi bloccare (OK dare all'utente povero uno stroboscopio) fino a quando non viene ricevuto il prossimo messaggio di aggiornamento. Oppure, può avere un messaggio di "aggiornamento in sospeso" nell'area dell'intestazione che si trasforma in "aggiornamento" o in realtà ha l'aggiornamento dell'interfaccia utente (fai attenzione se l'utente è su qualcos'altro ...)

Potresti non voler lanciare tutti questi nuovi pezzi di infrastruttura nel tuo negozio. Ma alzarsi in piedi pub / sub (inversione del modello di comunicazioni SOA) ti offre così tante opzioni, salti di gioia.

    
risposta data 24.01.2015 - 03:35
fonte

Leggi altre domande sui tag