Approccio progettuale basato sul dominio senza ORM

The item I am struggling with is how to design the domain layer without ORM since ORM would handle fetching items lazy or eager depending on how mappings are configured.

In genere, i componenti del dominio operano nello stato di memoria, senza integrarsi con le porte e gli adattatori del sistema. Pensa onion architecture .

Una seconda idea importante è assicurarsi che il modello di dominio sia il più esplicito possibile sulle informazioni necessarie. Questo di solito viene fatto con l'astrazione di un repository, ma in cui il contratto è specifico per il caso d'uso del dominio. Udi Dahan (2007) ha toccato l'idea.

Quindi il dominio richiede al repository il minimo necessario per soddisfare i propri requisiti e l'implementazione sotto le copertine calcola come recuperare lo stato necessario e da esso creare un modello in memoria di quello stato.

Sì, nel caso patologico, potresti finire con un sacco di implementazioni di repository che ritagliano dati specifici da Oracle. Succede.

DI framework in realtà non figura in esso a meno che tu non abbia intenzione di eseguire il modello di dominio in molti ambienti diversi; hai solo bisogno di discovery del repository, ovvero una factory che fornisce la corretta implementazione del repository su richiesta (ovvero il repository "repository").

Se non si utilizza uno strumento ORM, è necessario eseguire personalmente l'ORM. Sfortunatamente, ORM aggiunge un alto livello di complessità. Esistono alcune strategie per affrontare le sfide alle quali hai fatto riferimento.

Includi il repository nell'oggetto dominio

Pro: consente il caricamento lento. Il modello di dominio mantiene la manipolazione dei dati piuttosto semplice mentre consente al componente del repository di eseguire il livello di persistenza.

Con : potresti causare più chiamate al database in alcuni casi in cui uno sarebbe stato sufficiente. Può essere più difficile usare il database per fare il filtraggio per te. Ciò significa maggiore utilizzo della memoria e manipolazione degli oggetti.

Serializza tutto dal repository

Pro: Hai il pieno controllo del processo di persistenza senza attivare chiamate successive al database. Puoi usare il database per applicare filtri, ecc. Molto più facilmente.

Con: Può essere molto costoso quando tutto ciò di cui hai bisogno è un sommario dei dati in un elenco di grandi dimensioni.

Qualcosa in mezzo

Alcune lezioni che ho imparato durante la progettazione di un'app su un database NoSQL mi hanno fatto riflettere in modo un po 'diverso su come stavo separando i dati. So che per il momento quella soluzione è fuori dal tavolo. Tuttavia, alcune delle stesse strategie si applicano a DDD:

• Pensa a dove deve essere la separazione. Ho scoperto che alcuni oggetti "di riferimento" leggeri erano ottimi per fornire le informazioni di riepilogo per gli elenchi, senza ottenere tutto dai bambini. Ottenere il genitore e gli oggetti figlio di riferimento è stato abbastanza veloce e permettimi di popolare completamente lo schermo.
• Non aggiungere nulla di cui non hai bisogno finché non ne hai bisogno. Se si sceglie di ottenere tutto in una volta e questo inizia a rallentare l'app, è possibile aggiungere la complessità del caricamento lento quindi.
• Aggiungi test man mano che procedi.

Il DDD è sia potente che diverso dalle attuali conoscenze su come creare applicazioni. Trovo che il DDD favorisca gli ambienti in cui tutto è in un livello come un'applicazione desktop. Con le applicazioni Web, è necessario essere in grado di serializzare oggetti da e verso JSON e fare in modo che lo schermo reagisca in modo appropriato. La logica che applichi scrupolosamente nel livello dell'applicazione Web non viene trasmessa automaticamente al browser web. Penso che sia per questo che il modello di dominio anemico è un po 'più popolare in questi giorni.

Dirò che l'utilizzo di un database NoSQL risolve un certo numero di problemi che circondano la complessità che è ORM. Se / quando puoi dare un'occhiata a questo, vedrai come risolve un certo numero di problemi per te.

Sono confuso dall'implicazione che non usare un ORM sarebbe una sfida per la progettazione basata sul dominio. Se qualcosa che utilizza un ORM rende più difficile creare un modello di dominio appropriato, nella mia esperienza.

Quindi la vera domanda qui è come crei gli oggetti dai dati, giusto? Mi viene da pensare che lavorare con i database sia un'arte così persa che la gente pensa che l'ORM sia una necessità. La domanda è quali strumenti si utilizzano per interrogare e aggiornare. Esistono strumenti come MyBatis che possono aiutarti a gestire le connessioni ecc. E utilizzare l'SQL reale. Il caricamento pigro / ansioso non è difficile da implementare. Stai cercando aiuto in termini di design / tecniche?

Mi aspetto che gli oggetti del dominio abbiano una logica minima su zero mentre il repository li utilizza semplicemente e, possibilmente, alcuni DTO per passare dal repository agli oggetti del dominio.

Nel progetto a cui sto lavorando, abbiamo cose come "CoffeeCup" e "CoffeeCupRo", dove quest'ultimo è un oggetto repository che comprende il layout del repository e ha metodi per la conversione da e verso gli oggetti del dominio. Sembra che risolverebbe anche il tuo problema.

I commenti mi hanno insegnato che questa è una cattiva idea e non dovresti ripetere il nostro errore.