È corretto chiamare un database o un documento un "Modello", come in Model / View / Controller?

MVC è un modello di progettazione.
Loro (schemi di progettazione) non hanno lo scopo di trattenerti nel modo in cui vengono utilizzati e / o implementati. Dovrebbero essere un meccanismo di comunicazione che ti consente di trasmettere idee sulla tua applicazione ad altri programmatori (non un'implementazione).

E anche se normalmente mi aspetto che il modello sia più di un semplice dato (dato che la vista deve essere aggiornata quando il modello cambia). Ma come processo di documentazione o descrizione, mi piacerebbe che tu ti riferissi al "Dati" come modello purché ti aiuti a spiegare come funziona il sistema.

Non penso che sia molto importante come si chiamerebbe questo o quello, a patto che si ottenga la separazione delle preoccupazioni da MVC in modo corretto.

Secondo me, MVC come termine è solo relativo al codice, non ai dati che sta elaborando. Nel tuo esempio, il DB sarebbe l'archiviazione, mentre il modello è quello che nel tuo codice "apre" e "espone" questa memoria ad altre parti del tuo programma (ad esempio il controller).

Sì, è una valutazione equa e in realtà non è troppo lontano dal modello Active Record di Rails. MVC è un pattern dell'interfaccia utente, e non interessa come strutturi il tuo livello di dominio - solo che lo tenga separato dai gestori di azioni View e UI (il Controller).

Detto ciò, quello che stai descrivendo probabilmente cadrà in un anemico dominio anemico - che va bene per un sacco di applicazioni, ma dovresti fare attenzione anche alle insidie. Il principale è la tendenza del Controller a riprendere il gioco e iniziare ad assorbire la logica che dovrebbe appartenere al dominio (come la validazione o l'orchestrazione). O la crescita di un livello di servizio che vive accanto al dominio e contiene tutta la logica.