Consigli sulla progettazione di applicazioni Web con una durata di oltre 40 anni

Scenario

Attualmente sono parte di un progetto sanitario il cui requisito principale è acquisire dati con attributi sconosciuti utilizzando moduli generati dagli utenti da fornitori di servizi sanitari. Il secondo requisito è che l'integrità dei dati è fondamentale e che l'applicazione verrà utilizzata per oltre 40 anni. Attualmente stiamo migrando i dati del cliente dagli ultimi 40 anni da varie fonti (Paper, Excel, Access, ecc ...) al database. I requisiti futuri sono:

• Gestione del flusso di lavoro dei moduli
• Pianifica la gestione dei moduli
• Sicurezza / Gestione basata sui ruoli
• Motore di segnalazione
• Supporto per dispositivi mobili / tablet

Situazione

Solo 6 mesi dopo, l'attuale architetto (programmatore) / programmatore senior ha adottato un approccio "veloce" e ha progettato un sistema scadente. Il database non è normalizzato, il codice è accoppiato, i livelli non hanno scopi specifici e i dati iniziano a sparire poiché ha progettato alcuni bean per eseguire "eliminazioni" sul database. La base di codice è estremamente gonfia e ci sono lavori solo per sincronizzare i dati poiché il database non è normalizzato. Il suo approccio è stato quello di fare affidamento su processi di backup per ripristinare i dati mancanti e non sembra credere nel re-factoring.

Dopo aver presentato le mie scoperte al Primo Ministro, l'architetto verrà rimosso al termine del suo contratto. Mi è stato affidato il compito di riprogettare questa applicazione. La mia squadra è composta da me e da un programmatore junior. Non abbiamo altre risorse. Ci è stato concesso un congelamento dei requisiti di 6 mesi in cui possiamo concentrarci sulla ricostruzione di questo sistema.

Ho suggerito di utilizzare un sistema CMS come Drupal, ma per motivi politici nell'organizzazione del cliente, il sistema deve essere costruito da zero.

Questa è la prima volta che progetterò un sistema con una durata di oltre 40 anni. Ho lavorato solo su progetti con una durata di 3-5 anni, quindi questa situazione è molto nuova, ma entusiasmante.

Domande

• Quali considerazioni di progettazione renderanno il sistema più "a prova di futuro"?
• Quali domande dovrebbero essere poste al cliente / PM per rendere il sistema più "a prova di futuro"?

I dati sono re

Penso che sia un po 'irragionevole aspettarsi che un'applicazione web intorno al 2013 sia ancora attiva e funzionante nel 2053. Le tecnologie cambieranno. Le piattaforme andranno e verranno. Ormai l'HTML potrebbe essere un ricordo singolare. Ma i tuoi dati saranno ancora in giro.

Quindi i dati sono il tuo obiettivo principale. Finché i tuoi dati sono ancora lì, le persone saranno in grado di adattarsi a qualunque nuova tecnologia avvenga. Assicurati che i tuoi schemi di dati siano ben pensati e adatti all'espansione. Prenditi il ​​tuo tempo specificandoli.

Per quanto riguarda le applicazioni effettive, la tua azienda probabilmente ha ragione qui nell'avere una direttiva "build da zero". Mantengo un paio di app Web di oltre 10 anni e sono molto contento che non siano bloccati nei sistemi CMS prevalenti del 2003. Usano framework sviluppati in casa, molto semplici. Penso che per qualcosa del genere tu stia meglio con un framework molto semplice che crei appositamente per le esigenze del progetto.

Ma la realtà è che, nell'arco di 40 anni, l'azienda (si spera) realizzerà alcuni servizi front-end e back-end per adattarsi alle piattaforme in evoluzione. Detto questo, avrei come target una durata di 5-10 anni per le singole applicazioni rivolte all'utente.

Produciamo software che è stato utilizzato da clienti paganti per oltre 20 anni. La base di codice ha superato diverse generazioni di strumenti di controllo del codice sorgente. Il nostro software raggiunge tutti i tuoi punti elenco tranne quello del tablet.

Alcune delle preoccupazioni includono ESIGN e UETA . I nostri avvocati ritengono che dobbiamo mantenere i record elettronici leggibili per un minimo di 10 anni. Per i documenti che vengono mantenuti intero, si dovrebbe guardare in PDF / A .

Per il tuo database, non preoccuparti troppo della normalizzazione. Invece dovresti preoccuparti di registrare tutto e avere tabelle di controllo che tengono traccia delle modifiche / eliminazioni nei dati. Quando esegui l'upgrade delle versioni, pianifica di testare le nuove versioni in parallelo per un tempo sufficiente a garantire la migrazione dei dati. Questo test delle nuove versioni include anche nuovi sistemi operativi: abbiamo avuto sorprese molto spiacevoli nel corso degli anni. Conservare i supporti di installazione e le chiavi di licenza nel caso in cui sia necessario eseguire un rollback. Test di backup. Se si desidera serializzare gli oggetti da archiviare nel database, utilizzare XML anziché la serializzazione fornita dal framework di sviluppo.

Per il personale, le basi di codice a lungo termine richiedono memoria a lungo termine. Idealmente, vorresti avere persone in giro che sono in giro da molto tempo. Se ciò è istituzionalmente impossibile, allora devi documentare tutto in qualcosa come un wiki. E il mio consiglio è un wiki che può essere collegato al tuo sistema di tracciamento dei bug.

Per il tuo codebase, assicurati di avere commenti nel tuo codice. La migrazione da un sistema di controllo della versione a un altro perderà quasi sempre i commenti del check-in. Sono un fan dei test delle unità di denominazione dopo i numeri delle specifiche e dei bug. In questo modo se il test unitario si Test_Bug_1235 interrompe, allora sai cosa e dove rintracciare cosa dovrebbe testare. Non è così "sexy" come nominare i tuoi test, Check_File_Save_Networked_Drivesma quel tipo di test è difficile da rintracciare a specifiche, requisiti o bug a differenza Test_requirement_54321_case_2.

Invece di provare a capire come questa applicazione sarà ancora in funzione tra 20 anni, penso che dovresti passare i tuoi sei mesi a risolvere i problemi che hai scoperto che l'architetto originale ha causato, a creare un'architettura sensata, robusta e andare avanti da lì.

La de-normalizzazione parziale di un database non è necessariamente del tutto inaspettata in un contesto medico. Alcune parti dei database medici presentano caratteristiche che le rendono idonee al modello EAV (Entità / Attributo / Valore) .

Risposta da una prospettiva front-end:

Non ascoltare tutti dicendo che non si può fare, perché un servizio web sperimentale della San Francisco State University che ho co-scritto nel 1996 finalmente è andato in paradiso Internet un paio di anni fa e in quel momento non ho mai avuto bisogno di una soluzione di compatibilità con un singolo browser ; questa è quasi la metà del tuo obiettivo di 40 anni. E questo front-end basato su JavaScript che ho realizzato nel 1998 per un progetto dello Stanford Research Institute è stato sostituito con qualcosa di più appariscente qualche anno dopo, ma non c'è motivo per cui l'interfaccia utente originale non possa essere ancora in esecuzione oggi con correzioni di compatibilità minori.

Il trucco è garantire che la tua app utilizzi solo standard W3C / ECMA ampiamente supportati e abbia un design pulito sotto il tuo controllo. Mentre molte app Web scritte con la tecnologia alla moda degli anni '90 non funzionano bene o per niente oggi, le app web degli anni '90 scritte secondo i principali standard funzionano ancora. Possono sembrare passé, ma funzionano.

L'obiettivo qui non è quello di scrivere un'app Web che salirà sul loro server e rimarrà lì per 40 anni senza che nessuno lo tocchi più. Serve a costruire una base che possa ancora essere utilizzata decenni fa, che può crescere per supportare nuove funzionalità senza dover essere ricostruita da zero.

Prima di tutto, devi codificare secondo gli standard ufficiali e solo verso gli standard ufficiali. Nessuna funzionalità JavaScript non fa parte di uno standard ECMAScript ratificato; ES5.1 è la versione corrente ed è generalmente supportata, quindi è sicuro targetizzare. Allo stesso modo, le versioni correnti di HTML5, CSS e Unicode sono buone. Nessuna funzionalità sperimentale JavaScript, CSS3 o HTML (quelle con prefissi fornitore o senza accordo al 100% tra i browser). E nessun hack di compatibilità specifico del browser. Puoi iniziare a utilizzare una nuova funzionalità una volta che è nello standard e tutti la supportano senza prefissi.

Il supporto ES5 significherebbe far cadere IE8 o versioni precedenti, cosa che suggerisco comunque poiché richiede hack specifici per browser che saranno inutili tra un paio d'anni. Suggerirei la modalità rigorosa ES5 per la migliore possibilità di longevità, che in realtà imposta la compatibilità del tuo browser di base su IE10 e le versioni recenti di tutti gli altri . Questi browser hanno anche il supporto nativo per molte delle funzionalità di validazione dei moduli e segnaposto di HTML5, che saranno utili per molto tempo.

Le nuove edizioni di ECMAScript mantengono la compatibilità con le versioni precedenti, quindi sarà molto più semplice adottare le funzionalità imminenti se il tuo codice è scritto secondo gli standard attuali. Ad esempio, le classi definite utilizzando la classsintassi imminente saranno completamente intercambiabili con le classi definite con la constructor.prototypesintassi corrente . Quindi in cinque anni uno sviluppatore può riscrivere le classi nel formato ES6 su base file per file senza interrompere nulla, supponendo, ovviamente, che anche tu abbia buoni test unitari.

In secondo luogo, evitare i framework di app JavaScript di tendenza, soprattutto se cambiano il modo in cui si codifica l'app. La spina dorsale era di gran moda, poi SproutCore ed Ember lo erano, e ora Angular è il framework che tutti amano promuovere. Possono essere utili, ma hanno anche qualcosa in comune: spesso rompono le app e richiedono modifiche al codice quando escono nuove versioni e la loro longevità è discutibile. Di recente ho aggiornato un'app Angular 1.1 alla 1.2 e ho dovuto riscrivere parecchio. Allo stesso modo, passare da Backbone 2 a 3 richiede molte modifiche HTML. Gli standard si muovono lentamente per un motivo, ma questi quadri si muovono rapidamente e le cose si rompono periodicamente sono il costo.

Inoltre, i nuovi standard ufficiali spesso lasciano obsoleti i vecchi framework, e quando ciò accade, tali framework o mutano (con cambiamenti di rottura) o vengono lasciati indietro. Sai cosa succederà a tutte le biblioteche promettenti concorrenti del mondo una volta ratificato ECMAScript 6 e tutti i browser supporteranno la sua classe Promise standardizzata? Diventeranno obsoleti e i loro sviluppatori smetteranno di aggiornarli. Se scegli il giusto framework, il tuo codice potrebbe adattarsi abbastanza bene, e se hai indovinato male, vedrai un refactoring importante.

Quindi, se stai pensando di adottare una libreria o un framework di terze parti, chiediti quanto sarà difficile rimuoverlo in futuro. Se si tratta di un framework come Angular che non può mai essere rimosso senza ricostruire la tua app da zero, è un buon segno che non può essere utilizzato in un'architettura di 40 anni. Se si tratta di un widget di calendario di terze parti che è stato estratto con un middleware personalizzato, la sua sostituzione richiederebbe alcune ore.

In terzo luogo, dagli una struttura per app buona e pulita. Anche se non stai utilizzando un framework per app, puoi comunque sfruttare gli strumenti per sviluppatori, creare script e un design pulito. Personalmente sono un fan della gestione delle dipendenze di Closure Toolkit perché è leggero e il suo overhead viene completamente rimosso durante la creazione della tua app. LessCSS e SCSS sono anche ottimi strumenti per organizzare i fogli di stile e creare fogli di stile CSS basati su standard per il rilascio.

Puoi anche organizzare il tuo codice in classi monouso con una struttura MVC. Ciò renderà molto più facile il ritorno di diversi anni nel futuro e sapere cosa stavi pensando quando hai scritto qualcosa, e sostituire solo quelle parti che ne hanno bisogno.

Dovresti anche seguire i consigli del W3C e tenere le informazioni di presentazione completamente fuori dal tuo HTML. (Ciò include trucchi come dare agli elementi nomi di classe di presentazione, come "big-green-text" e "wide-column-wide".) Se il tuo HTML è semantico e CSS è presentazionale, sarà molto più facile mantenerlo e adattarlo verso nuove piattaforme in futuro. Sarà anche più facile aggiungere supporto per browser specializzati per non vedenti o disabili.

In quarto luogo, automatizza i test e assicurati di avere una copertura quasi completa. Scrivi unit test per ogni classe, sia sul lato server che in JavaScript. Sul front-end, assicurati che ogni classe si comporti secondo le sue specifiche in ogni browser supportato. Automatizza questi test dal tuo bot di build per ogni commit. Ciò è importante sia per la longevità che per l'affidabilità, poiché è possibile rilevare i bug in anticipo anche quando i browser attuali li oscurano. Entrambi i framework di test basati su JSUnit di Jasmine e Google Closure sono buoni.

Ti consigliamo inoltre di eseguire test funzionali dell'interfaccia utente completa, su cui Selenium / WebDriver sono bravi. Fondamentalmente, scrivi un programma che attraversa l'interfaccia utente e lo utilizza come se una persona lo stesse testando. Collegali anche al robot di costruzione.

Infine, come altri hanno già detto, i tuoi dati sono re. Pensa al tuo modello di archiviazione dei dati e assicurati che sia costruito per durare. Assicurati che il tuo schema di dati sia solido e assicurati che sia testato accuratamente anche ad ogni commit. E assicurati che l'architettura del tuo server sia scalabile. Questo è ancora più importante di qualsiasi cosa tu faccia sul front-end.

Lasciando da parte i problemi delle irragionevoli aspettative del tuo cliente e concentrandomi sui problemi del design, non andrei fino a 40 anni, ma il problema che tu sembra avere, di evolvibilità a lungo termine, è esattamente ciò per cui REST è stato creato . Con questo intendo davvero REST come stile di architettura, non lo sviluppo guidato da parole d'ordine così comunemente associato al termine in questi giorni.

In una certa misura, le persone sbagliano REST perché non sono riuscito a includere abbastanza dettagli sulla progettazione del tipo di media nella mia tesi di laurea. Questo perché ho esaurito il tempo, non perché pensavo che fosse meno importante degli altri aspetti di REST. Allo stesso modo, sospetto che molte persone sbagliano perché leggono solo la voce di Wikipedia sull'argomento, che non si basa su fonti autorevoli.

Tuttavia, penso che la maggior parte delle persone commetta l'errore che dovrebbe essere semplice progettare cose semplici. In realtà, lo sforzo richiesto per progettare qualcosa è inversamente proporzionale alla semplicità del risultato. Come vanno gli stili architettonici, REST è molto semplice.

REST è una progettazione software su scala decennale : ogni dettaglio è destinato a promuovere la longevità del software e l'evoluzione indipendente.

http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-724

Hai detto che intendi utilizzare un'interfaccia RESTful. Quel commento da solo suggerisce che dovresti fare qualche seria ricerca in questo e cercare di capire di cosa si occupa davvero REST. Probabilmente lo stai associando semplicemente alla mappatura dei metodi HTTP alle operazioni CRUD che la maggior parte delle persone pensa che sia REST, ma non ha nulla a che fare con quello.

Pensa a REST come a una formalizzazione dell'architettura del web stesso. In un modo o nell'altro, ci sono molte parti del web scritte una decina di anni fa o più che sono ancora disponibili e che possono essere utilizzate con un client creato oggi, quindi abbiamo qualcosa di giusto in quel dipartimento. Ci vorrà molto lavoro, te lo garantisco, perché fare REST nel modo giusto è difficile, ma ne vale la pena per i benefici a lungo termine.

Dopo aver letto la domanda e le altre risposte (molto ben ponderate), ho pensato che avrei lasciato anche i miei due centesimi. Nota: non devo assolutamente mantenere nessuna applicazione / software molto vecchio. Quello che uso come riferimento è la mia app web hobby in corso di lavoro che acquisisce alcuni dati governativi aperti, li analizza e li visualizza in diversi formati. L'app è iniziata come un progetto in cui non ero solo e in cui il governo ha appena annunciato che offrirà questi dati in qualche modo, in qualche modo. Quindi era chiaro che molte cose cambieranno nel tempo. E lo hanno fatto. Cosa ho imparato da esso:

• Dividi le cose in mini-applicazioni. Ognuno in grado di svolgere il proprio compito da solo. Questo rende il passaggio di un singolo pezzo molto veloce, molto sicuro e molto semplice. E quando devi rientrare, non è davvero difficile aggirare il motivo per cui le cose accadono e come accadono. Se tu o qualcun altro dovrete cambiare qualcosa in seguito, è più facile sostituire una singola parte rispetto a un intero insieme di cose.
• Ottieni un middleware / player solido e costante che viene utilizzato per la comunicazione tra le diverse parti. In questo caso ho usato JSON, ma anche XML, ini o standard simili andrebbero bene. È facile da ripetere e può essere trasformato in quasi tutto. Tutti sono standard comprovati che sopravviveranno per un po 'di tempo. Anche se i dati sottostanti e / o il modello di archiviazione cambieranno. Ognuna delle app può utilizzare la propria memoria dati per il proprio compito specifico. Ciò riduce la quantità di dati scansionati per un'attività, quindi più facile da gestire e mantenere ed è più facile da scambiare.
• Non preoccuparti delle decisioni relative al linguaggio di programmazione. Quelli cambieranno nel tempo. Assicurati solo di usare la lingua con cui ti senti a tuo agio o che si adatta meglio a un'attività.
• Assicurati che l'archiviazione dei dati sia "scalabile orizzontalmente" e che sia facile collegare moduli di archiviazione aggiuntivi.
• Ottieni un punto comune (nel mio caso sono gli URI) in cui le mini-app vengono chiamate e / o scambiano dati.

Riassumendo: la cosa a cui tengo di più è la separazione delle preoccupazioni e la capacità di scambio delle parti assegnate per le attività. Sai semplicemente che in 40 anni (anche in 5 o 10) hardware, interfacce, archiviazione, ecc. Cambieranno molto. E in seguito gli sviluppatori dovranno reagire a tali modifiche e scambiare parti della propria applicazione, sia essa il contenitore di dati o parti dell'interfaccia utente.

Per rendere le cose il più "a prova di futuro" possibile, pianificare un cambiamento. Cioè, fai del tuo meglio per non ottimizzare nulla se non la possibilità di cambiare facilmente. Quindi nessuna normalizzazione, nessuna convalida rigorosa e abbondanza di accoppiamento libero.

• Utilizza le principali tecnologie open source. Per i dati, i sistemi a fonte chiusa sono una delle principali fonti di rischio in quanto non si può pianificare su quali aziende passeranno o cambieranno strategie, portando con sé tutto l'accesso ai dati. Inoltre, anche piccoli progetti open source senza una vivace comunità hanno maggiori probabilità di perdere il supporto.

• Utilizzare un database NoSQL senza schema. Il tipo di dati non strutturati utilizzati è quasi uscito dal libro di testo per un archivio di documenti come MongoDB. I database relazionali tradizionali e la loro normalizzazione sono utili quando sai come saranno strutturati i tuoi dati, ma è davvero una finzione, soprattutto qui. I costi di modifica dello schema in un RDBS diventano sempre più grandi man mano che il sistema si espande. Sappi che qualunque struttura verrà scelta ora finirà per cambiare.

• Disaccoppiare pesantemente il sistema usando standard ampiamente accettati. La demolizione di tutti gli accessi ai dati e la mutazione nei servizi web è un passo verso questo. La combinazione di questo con le code dei messaggi per l'invio di modifiche e simili aiuterà le singole parti del sistema a cambiare le lingue o le tecnologie nel tempo.

OK, quindi dirò alcune cose che probabilmente saranno piuttosto impopolari, ma restate con me qui.

Dato che questo è il tuo primo progetto in cui i dati e / o l'applicazione dovrebbero durare più di 20 anni e sei tu a guidare il progetto, devi fare un passo indietro e pensare a quali sono le probabilità di questo progetto. . Perché sono praticamente vicini allo zero.

È necessario dedicare molto tempo a concentrarsi sulla progettazione del database e ottenere ciò giusto. Affinché questo progetto abbia successo devi inserire un architetto di dati nel progetto, e prima piuttosto che successivamente. Senza qualcuno che abbia esperienza nella progettazione di database e che sia ben addestrato a guardare avanti in che modo i dati potranno essere utilizzati in futuro, le probabilità che i dati siano ancora utili dopo 5 anni e molto meno 40 anni non sono affatto ridotte.

Aspettarsi che due persone (una delle quali abbia il titolo di jr. Dev) costruisca qualcosa da zero che dovrebbe durare 40 anni, probabilmente non ci riuscirà. Dovrebbe esserci un team di persone molte delle quali hanno esperienza nel lavorare con grandi progetti come questo che stanno lavorando alla progettazione dei dati, alla progettazione delle API e alla progettazione delle applicazioni. Qualcosa del genere non è un progetto per 2 persone.

Volendo legare il progetto a qualcosa come Drupal mostra perché il progetto ha bisogno di persone abituate a lavorare su questo tipo di progetti. Non vuoi legare l'applicazione a qualcosa che potrebbe andare fuori moda nel giro di pochi anni. In tal caso, trovare qualcuno con cui lavorare sul sistema in 5-10 anni potrebbe diventare molto difficile molto rapidamente.

Darei questo consiglio alla direzione e spiegherei loro che è necessario coinvolgere più persone anziane nel progetto. Altrimenti il ​​progetto è destinato a fallire e probabilmente finirai per essere quello che si prende la colpa.

L'applicazione non deve sopravvivere a 40 anni senza alcuna evoluzione. Ma, poiché sarebbe o dovrebbe essere costruito da zero, potrebbe ancora essere "funzionante".

La cosa più importante è l '"architettura dei dati" che consente stabilità e governance oltre che estensibile.

Abbiamo progettato un'architettura dei dati e una tassonomia che potrebbero quasi sopravvivere alla fine dell'umanità ma essere comunque estensibili. Devi trovare una vera persona di TASSONOMIA DEI DATI / ARCHITETTURA DEI DATI per farlo per te.

La chiave qui è concentrarsi sul database (come hanno già detto molti sopra). Questo deve essere coerente e descrivere completamente l'operazione. Deve crescere con l'operazione mentre cambia. Se non è facile cambiare, diventerà obsoleto e questo è il bacio della morte. Il resto è relativamente meno importante.

Non sono d'accordo con quelli sopra che suggeriscono che la normalizzazione non è importante, anche se ci sono sempre casi in cui i sistemi attuali non sono all'altezza del lavoro. In questi casi denormalizzare ma assicurarsi che il database gestisca le scritture / modifiche extra come parte di una transazione atomica. In questo modo è possibile ignorare efficacemente il problema fino a quando non è possibile risolverlo.

La società per cui ho lavorato prima del pensionamento gestisce un sistema che è stato scritto da zero ed è cresciuto quasi continuamente per 25 anni e copre praticamente tutti gli aspetti di un rivenditore medio. Gli aspetti di questo sistema che ritengo importanti sono:

• L'integrazione è vitale.
• Il database deve essere il più corretto e comprensibile sia per l'IT che per gli altri membri del personale, quindi è necessaria un'enfasi quasi paranoica sulla denominazione. Abbiamo tabelle di mnemonici definiti che vengono poi combinati per creare nomi di tabelle e campi e tutti i "codici" sono stati ugualmente nominati come costanti e memorizzati in una struttura di tabelle EAV.
• Abbiamo incapsulato la logica aziendale in trigger di database. All'inizio questo è doloroso e richiede un lavoro aggiuntivo per trasmettere messaggi di errore ai client e per consentire ai trigger di essere modificati in modo flessibile senza bloccare l'intera tabella su alcuni sistemi, ma questo diventa rapidamente un enorme risparmio di tempo e costringe il database ad essere molto più corretto che altrimenti.
• Supponiamo che manterrai almeno le tabelle di riferimento (idealmente tutte le transazioni tranne quelle più veloci e meno importanti) per la vita del sistema, anche se "cancellate", quindi i tuoi riferimenti sono corretti.
• A causa di quanto sopra, assicurarsi che eventuali identificatori univoci e numeri di transazione siano dimensionati a lungo termine. (Inizialmente ho scherzosamente suggerito che dovevano durare fino a quando non mi sono ritirato).

Suggerirei di utilizzare la generazione di eventi e la segregazione delle responsabilità di comando e query . Questo principalmente perché l'unica cosa di cui puoi essere sicuro sono gli eventi che sono già apparsi. Potrebbero venire nuovi tipi di eventi. Quindi, anche se poni pensieri pesanti su un modello, è sicuro che questo diventerà obsoleto. La migrazione di tutti i dati con ogni versione potrebbe non essere fattibile. Quindi il migliore è avere un modello che si adatti alle tue attuali esigenze e che viene calcolato da eventi già registrati ogni volta che ne hai bisogno e quindi distribuire eventi che sono calcolati dallo stato corrente di quel modello.

Tieni a mente anche i test. Se l'applicazione è in uso tra dieci anni, i tester devono assicurarsi che stia ancora facendo ciò che dovrebbe fare. Rendi quindi il test di integrazione la tua applicazione il più semplice possibile.