L'architettura del mio progetto è comune? Qual è il suo nome?

Sono responsabile di un progetto software da alcuni anni a questa parte (un'applicazione desktop Java, principalmente basata su eventi). L'ho avviato da zero e all'inizio di questo progetto ho fatto delle scelte forti sull'architettura del software.

La mia architettura

Ho introdotto la classe Module , che rappresenta una parte funzionale dell'applicazione, con una responsabilità ben definita. L'unica cosa che Module espone al mondo è un insieme di "handle di comunicazione". Esistono 4 tipi di handle di comunicazione:

• un Emitter<T> può emettere un messaggio di tipo T .
• a Handler<T> può ricevere un messaggio di tipo T
• a Puller<R, Q> può fare una query rappresentata da un messaggio di tipo Q , e riceverà un messaggio di risposta di tipo R
• a PullServer<R, Q> può ricevere una query rappresentata da un messaggio di tipo Q e restituirà un messaggio di risposta di tipo R .

Quindi, all'inizio dell'esecuzione dell'applicazione, installo tutti i moduli che compongono l'applicazione e imposto tutte le connessioni tra di loro. Un Emitter può essere collegato a uno o più Handlers , e un PullServer può servire uno o molti Pullers (i tipi di questi due endpoint devono essere compatibili, ovviamente).

Tutte le classi utilizzate per rappresentare un messaggio sono immutabili e sono definite in un sottoprogetto. Ogni Module dipende da quel sottoprogetto e nient'altro. Questo rende il Modules molto disaccoppiato (un Module non sa nulla sull'altro Modules , e il loro input / output verso il mondo esterno è molto chiaro). Inoltre, l'aspetto dinamico dell'applicazione (il flusso di dati) è definito in un luogo unico, nella funzione main . Inoltre, è super facile testare un Module , dobbiamo solo fornire% co_de falso e Emitters , e collegarlo a PullServers Module e Handlers .

I miei pensieri su questa architettura

Quindi, questo è il primo "grande" progetto software su cui lavoro, e ho inventato questo progetto perché mi sembrava la cosa giusta da fare. Ora, il progetto funziona perfettamente, con un totale del 57% diPullers che lavora insieme.

Uno dei miei collaboratori, che ha aderito al progetto di recente, mi ha chiesto se si trattava di un'architettura comune, se c'era un nome per un tale progetto. Non ho una risposta, dal momento che non ho molta familiarità con altre architetture software reali.

Mi sembra che questo progetto sia vicino al concetto di attori, che possiamo trovare in linguaggi come Scala (e forse Erlang). Tuttavia, gli attori non forniscono il disaccoppiamento fornito dal mio progetto. E gli attori hanno una capacità aggiuntiva: ogni attore ha una propria coda di messaggi e un proprio thread di esecuzione (tipo di).

Inoltre, penso che il mio design sia in qualche modo correlato al modello di Iniezione di dipendenza, nel senso che le dipendenze tra Modules sono definite in un punto centrale. Tuttavia, questo modello riguarda le interfacce, non i messaggi. Non definisce come i moduli comunicano (notifica, richiesta / risposta).

La domanda (finalmente!)

Sai di un progetto software che è simile all'architettura? C'è un nome per questo?

Modifica

@Doc Brown suggerisce che questo design è simile a Flow Design . Non posso essere più d'accordo. Ecco un confronto uno a uno tra questi due progetti:

• Il mio modulo è la stessa cosa di un'unità funzionale .
• Il mio emettitore / gestore è lo stesso di pin di uscita / pin di input , tranne il mio non ha un nome. Nella mia progettazione, le "maniglie di comunicazione" sono identificate solo dai loro tipi.
• Le connessioni tra i miei moduli sono l'equivalente dei loro fili .
• Il mio Puller / PullServer è simile alle loro relazioni di dipendenza . Tuttavia, dicono che esiste una dipendenza esplicita dal chiamante al chiamato. Nel mio disegno sono disaccoppiati.
• Definiscono il concetto di Schede . È interessante, penso che prenderò in prestito questa idea!
• Definiscono il concetto di Configurazione . Ho bisogno di configurare un modulo nel mio programma e per questo definisco un gestore di configurazione su alcuni dei miei moduli.
• Entrambe le soluzioni sono sincrone.
• Non ho il concetto di mappa e unisco . Ma non ne sento il bisogno.

Ben trovato, Doc!