Quanti livelli dovrebbero avere i miei modelli in un'app Web basata su DB?

In node.js generalmente utilizzo solo tre livelli.

Livello dati:

Un semplice livello che parla direttamente all'origine dati. È solo un lavoro che estrae in modo efficiente i dati dall'origine e scrive su di esso. L'origine dati può essere qualsiasi cosa, un endpoint TCP, un endpoint HTTP, un database, un filesystem, ecc.

Livello dominio:

Il livello dell'oggetto dominio. Questo è simile alla tua "M" in MVC. È una rappresentazione a oggetti di un oggetto dominio. Ha metodi di costruzione, manipolazione, validazione e altra logica.

Si noti che un singolo oggetto dominio può comunicare con diversi oggetti dal livello dati e che diverse viste possono trasformare un oggetto dominio.

Visualizza livello:

La vista prende un oggetto dominio e si trasforma in un modo facilmente stampabile. Ad esempio, nel livello vista, converto un timestamp in una stringa leggibile dall'uomo o eseguo la conversione della lingua i18n.

Fa anche qualsiasi altra logica di visualizzazione. Generalmente hai più oggetti di visualizzazione per un singolo oggetto di dominio.

Ovviamente converte anche i dati dall'oggetto dominio nel formato desiderato, sia esso binario, xml, json, html, alcuni protocolli arbitary TCP, testo normale, csv, ecc.

Livello IO

In genere hai anche bisogno di una qualche forma di IO layer che dialoghi con gli altri livelli.

vale a dire. il livello IO

• decomprime l'input
• chiama l'oggetto dominio corretto da dati o istanza di un oggetto dominio
• passa l'istanza di dati / dominio attraverso il livello di vista
• convoglia le informazioni non elaborate restituite dal livello vista (html / json / binary / ...) sull'output

Applicazioni multiple

Ora una singola applicazione ha questi tre livelli. Se avessi un sito Web dinamico, avrei questi tre livelli sul server e questi tre livelli sul client.

Se avessi la mia unica fonte di dati per parlare, allora quell'origine dati remota userebbe anche questi tre livelli, avrebbe i propri oggetti di dominio, il proprio livello di dati sulle proprie origini dati e il proprio livello di vista che altri i servizi parlano quando mi usano come fonte di dati.

Immagine carina

Fonte immagine

Le tue parole chiave sono "Modello di dominio Rich" e dovresti tenere presente antipattern del modello di dominio anemico .

Nelle mie applicazioni (Java) ho questi livelli:

1. Oggetti business (oggetto database + bahaviour relativo ai dati), mappato in modo trasparente su DB tramite Hibernate, iniettato con dipendenze del servizio utilizzando Spring anotation @Configurable - poiché contengono dipendenze, è possibile avere dati + operazioni in un unico punto - abbracciando il design OO (notare la differenza quando si utilizza un modello anemico, che ha dati in un livello e operazioni in un altro (questo approccio è procedurale e distrugge il polimorfismo e l'ereditarietà)).
2. Oggetti di accesso ai dati - Incapsulano le comunicazioni con DB, questo strato può essere facilmente scambiato, se decido di cambiare l'implementazione dell'accesso al DB (ad esempio da JPA a JDBC o forse DB oggetto)
3. Livello di servizio: contiene azioni che non operano su oggetti business (servizi hashich e crittografici) e servizi, che operano su un insieme di oggetti di business, quindi una sola BO non potrebbe avere questa responsabilità.
4. Facciata del servizio - Il vero livello del servizio così come è noto dal modello simile . Incapsula l'applicazione, fornisce API per le chiamate dal mondo esterno (solo quelle operazioni, che sono rilevanti per i chiamanti, senza problemi interni). La sicurezza e la gestione delle transazioni sono fatte qui. Così come la trasformazione dei dati interni in oggetti di trasferimento dati.
5. Oggetti di trasferimento dati: semplici wrapper, che contengono solo dati da trasportare nel mondo esterno all'applicazione. Non è possibile utilizzare il BO, perché hanno metodi, che non possono essere chiamati all'esterno senza contesto e, peggio, contengono dati privati. Solo immagine, se è saggio inviare UserBO a mondo esterno, quando contiene password hash e il sale. Anche DTO può differire da BO - potrebbero avere una granularità diversa.
6. Alcuni livelli di vista: utilizzo JavaServerFaces. Ma con questa implementazione, non importa, sarebbe lo stesso, se esistessero servizi web, REST o anche API binarie.

E un altro link per un altro buon articolo di Alistair Cockburn - Architettura esagonale / Porte e adattatori .