quando deve essere eseguita la modellazione dei dati?

1-Should data modeling (e.g ERD) be ignored at the beginning of a project and then be done later after the project is complete, especially if the project developers don't have all the details about the database at the beginning of the project?

Non ignorare la modellazione dei dati, dovrebbe essere trattato non appena inizierai a scrivere casi d'uso e la modellazione del progetto.

1. Concentrati sugli oggetti del mondo reale (dominio problematico)
2. Non confondere il modello di dominio per un modello di dati
   • Non confondere un oggetto (che rappresenta una singola istanza) con una tabella di database (che contiene una raccolta di cose)
3. Utilizza le relazioni di generalizzazione (is-a) e di aggregazione (has-a) per mostrare in che modo gli oggetti si relazionano tra loro
4. Non essere vittima della paralisi dell'analisi - limita sempre la tua sessione di brainstorming a poche ore e prova a convertire gli usi di utilizzo nella modellazione di domini e coprirai automaticamente la modellazione dei dati come movimento nel progetto passo dopo passo

La modellazione dei dati è la prima cosa che fai, non l'ultima!

Ogni parte del 99,9% di tutte le applicazioni è manipolazione dei dati o qualche tipo di presentazione. Se i tuoi sviluppatori non capiscono quei dati, non possono letteralmente farlo. In agile potresti riuscire ad andare avanti fino a un certo punto, ma è ancora il fondamento di qualsiasi app (in realtà "sistema" poiché spesso ci sono rapporti, riconciliazione, lotti, feed, servizi ecc. Che non hanno un utente ).

Direi che anche la tua azienda ha bisogno di un modello di dati per capire veramente come funziona e, ancora più importante, su cosa funziona.

In qualsiasi ambiente iterativo / agile, l'analisi e la progettazione dell'architettura e del modello di dominio è un processo continuo. Le ipotesi di base sono che all'inizio del progetto hai solo idee di base su cosa dovrebbe fare il software. E che nel tempo, i feedback di utenti, parti interessate e sviluppatori cambieranno (a volte drasticamente) il modo in cui il dominio dovrebbe essere rappresentato. L'idea che il dominio possa essere modellato come prima cosa nel progetto e che questo modello non cambi è irrazionale nel migliore dei casi.

Per raggiungere questo obiettivo, non dovresti concentrarti sulla modellazione del dominio, ma su come apportare modifiche al dominio in modo semplice e indolore. Ad esempio, in uno sviluppo non iterativo, c'è un'idea, quel documento che descrive il modello viene creato per primo (ERD) da cui viene creato il codice che lo implementa. Quindi qualsiasi modifica al modello deve essere eseguita due volte, una volta per il documento e una seconda per il codice. Ciò rende questo cambiamento più costoso da fare. Questo fa parte del Manifesto Agile come "Software di lavoro, una documentazione completa". Fa anche parte del Domain Driven Design, in cui il dominio è modellato non nel documento, ma nel codice.

Tutto questo è un'idea di architettura evolutiva . Che è un'ideologia che l'architettura non viene creata in una volta, ma si evolve nel tempo. E abbracciare questa ideologia consente la creazione di architetture più adatte al loro scopo. Ed è ancora una volta il pensiero agile che abbraccia il cambiamento invece di cercare di prevederlo.