Come gestisci i problemi di integrità dei dati legacy durante la riscrittura del software?

Forse è troppo ingenuo, ma hai pensato di creare un nuovo database per la tua nuova applicazione e scrivere un convertitore dal vecchio (mal progettato) database a quello nuovo?

Questo convertitore sarebbe difficile da codificare, ma otterrai alcuni dati più puliti da esso.

How should I deal with this legacy data that "breaks the rules".

Quindi il punto di partenza è parlare con gli esperti del tuo dominio. Cosa fanno oggi con i dati "non validi" nel sistema legacy?

Inoltre, il sistema legacy è il libro dei record? o descrive entità che sono effettivamente controllate da qualche altra parte? Un mix di entrambi? Potrebbe essere necessario prendere in considerazione strategie diverse.

Una possibile risposta è sostituire la convalida con un rapporto di eccezione. Fondamentalmente, invece di "che infrange le regole, non ti permetterò di farlo", la modella prende l'atteggiamento di "che infrange le regole, lo farò, ma ho intenzione di dirlo a te".

Il modello risolve i problemi, ma consente ai proprietari dei processi in questione di decidere cosa fare al riguardo.

La mia comprensione è che questa è una tecnica comune in sistemi in cui il modello di persistenza non è, in realtà, il sistema di registrazione. Pensa all'aeroporto: il gestore del bagaglio scansiona una targhetta per il bagaglio, dicendo al dominio che la valigia è a Heathrow. Invece di dire "non puoi scannerizzarlo, quella borsa dovrebbe essere ad Auckland", il sistema dice "hai scansionato quella cosa nel posto sbagliato, è meglio che informi un supervisore".

In questo approccio, penso che tu possa ancora essere aggressivo nel comando di convalida messaggi . Ad esempio, quando si traduce il comando per il dominio, è possibile creare i valori tramite una factory che impone le regole di coerenza dei dati. Questo di per sé dovrebbe mitigare molti dei problemi di immissione dei dati.

Ma dovresti lasciare che il repository sia permissivo sul salvataggio e sul caricamento degli aggregati. Dal lato della lettura, devi essere sicuro che un aggregato non valido non distrugga l'intera vista, ma se salti quegli aggregati, o semplicemente li contrassegni come sospetto dipenderà dal caso d'uso. Cavalli per i corsi.

Ma tu vuoi assolutamente essere in grado di supportare un rapporto sulle eccezioni - qui ci sono tutti gli aggregati che non sono attualmente conformi alle regole di validazione. E questo tipo di richiede di essere in grado di caricare una rappresentazione dell'aggregato che illustra il problema senza applicare le regole di convalida.

Hai bisogno di un esercizio di pulizia dei dati.

Non hai la possibilità di scrivere codice decente che funzioni se i dati esistenti rompono le regole che stai cercando di stabilire. Il tuo codice non ha colpa se applica le regole sui nuovi dati, ma non può gestire i vecchi dati che - dal suono di esso - non conoscerebbero una regola se ci si fosse avvicinati e avessero detto ciao. Il tuo codice non dovrebbe semplicemente farlo.

Se cerchi di piegare il tuo nuovo design ben congegnato per gestire i terribili vecchi dati, rovinerai il punto della riscrittura che hai appena fatto. Risulterà confuso e incoerente come i vecchi dati stessi.

Questo problema non è risolvibile scrivendo codice che indirizzi il database (e che deve aspettarsi che si comporti in modo coerente). Se il problema è nei dati, è qui che il problema deve essere risolto.

Chiunque stia conducendo questo progetto ti odierà per averlo detto, perché la pulizia dei dati costa tempo e fatica; ma è vero.