Diversi modelli interdipendenti, ciascuno con diverse fonti di dati: come evitare l'inferno e l'incubo

0

Attualmente sto lavorando a un progetto che richiede una struttura del modello complicata e sto lottando con la scelta dell'architettura giusta.

Prima di tutto, ci sono diversi modelli interdipendenti. Le modifiche in un modello possono innescare cambiamenti in molti altri modelli. Ad esempio, l'utente inserisce una query, il primo modello controlla il database per il tipo di query e il secondo modello richiede i suoi dati a seconda del tipo di query.

In secondo luogo, ogni modello può avere diverse origini dati. Le origini dati vengono utilizzate in modo condizionale, in base alla configurazione del sistema.

L'app deve funzionare senza problemi, ad esempio, se un'origine dati non restituisce le informazioni richieste, il modello deve provare a utilizzarne un'altra.

Una cosa importante è che il codebase verrà espanso con altri modelli. Quindi i modelli, le origini dati ecc. Devono essere molto modulari.

Attualmente esistono diversi modi in cui posso organizzare il livello del modello:

  1. Modelli "stupidi" ricreati dagli oggetti di fabbrica quando i dati di input (o un modello correlato) cambiano. Le dipendenze del modello vengono risolte in un oggetto operazione, incapsulando l'intera routine di aggiornamento. L'oggetto operazione è configurato ed eseguito da un modello di dominio. Però non so dove iniettare un'origine dati.

  2. Modelli "intelligenti" con logica di aggiornamento incapsulata in essi. Ogni modello richiede una sorta di mapper / data-source-manager, che funziona come proxy per diverse origini dati. I modelli segnalano i loro aggiornamenti a un modello di dominio. Le dipendenze sono risolte da un oggetto model controller o dependency manager.

Quale architettura è più appropriata qui?

Mi sto appoggiando al primo perché è (secondo me) meglio lavorare con modelli immutabili, aggiornando l'intero albero sul cambio di input. Questo approccio offre diversi vantaggi: ad esempio, è più facile serializzare come la presenza del modello è uguale a uno stato finito. Ma sono davvero incerto sulle origini dati ...

    
posta ivanmoskalev 14.12.2013 - 22:04
fonte

1 risposta

0

"Esistono diversi modelli interdipendenti: il cambiamento in un modello può far scattare cambiamenti in molti altri modelli."

Questo è esattamente ciò che dovresti evitare. Benvenuto in Hell.

Ho capito dalla tua domanda che la tua testa è nella tecnologia più che nel business. Penso che la risposta sia per te di cambiare leggermente la tua attenzione ...

La chiave per ridurre al minimo le dipendenze riguarda il modo in cui dividi un problema aziendale per risolverlo. Sembra che il design esistente stia già affrontando alcune sfide. Ciò rende più difficile il tuo lavoro in quanto non solo devi comprendere e interfacciarti con le esigenze aziendali, ma anche con i sistemi legacy che attualmente non soddisfano tali esigenze.

Vorrei dare una soluzione alla soluzione tecnica e tornare al business e porre loro 2 domande (di nuovo): Qual è il minimo assoluto necessario dal sistema al primo giorno? Dove vedi le funzionalità del sistema in futuro? Qualsiasi soluzione ha limiti e benefici. Comunicare i limiti / i vantaggi rilevanti per l'azienda (tralasciando i dettagli tecnici) e scoprire in che misura si adattano alle esigenze aziendali.

Con il business, design per il futuro, ma poi scegli un sottoinsieme di quel design da implementare per il momento. In questo modo lo terrete il più semplice possibile, senza doverti eliminare completamente dai cambiamenti che probabilmente dovrai apportare. Un altro piccolo trucco che a volte gioco è immaginare che il sistema aziendale e che ho appena progettato sia tutto implementato e quindi immaginare come verrà utilizzato con il business. Spesso questo prende in considerazione le considerazioni progettuali critiche che sono state trascurate. Usa i casi qualcuno? Il modo in cui l'azienda utilizzerà il sistema è super-critico ...

Non so quale delle tue soluzioni proposte finirai per scegliere, o se troverai una nuova soluzione. Non importa quanto fossi intelligente, se dovessi sceglierne uno per te, non sarebbe di aiuto come sceglierne uno in tandem con il business. Quello che aiuta di più il business è il modo migliore per andare.

Spero che questo aiuti. 24 visualizzazioni, 7 ore, nessuna risposta o commento ... ho pensato di dargli una pugnalata.

P.S. Se devi avere un failover da una sorgente di dati a un'altra, questo richiede un livello di riferimento da qualche parte . In definitiva, vorrei un livello nel mio codice che io possa chiedere i dati che mi servono e, se è disponibile, quel livello lo restituirà. Quindi posso scrivere dei clienti relativamente stupidi che dicono "Get me the data" e non "Get me the data using SQL-flavor A from Source # 1 ... se non funziona, prova a usare un altro linguaggio di query dalla fonte # 2 ... "Forse un servizio JSON / XML / YAML può incapsulare quella complessità? Forse restituisce una piccola nota di metadata oltre ai dati: "Dall'origine C perché A ha impiegato troppo tempo per rispondere e B ha dato un errore."

Mi sto semplicemente aggrappando al fail-over perché è il requisito più chiaro che ho ricevuto dalla tua domanda.

    
risposta data 15.12.2013 - 05:26
fonte

Leggi altre domande sui tag