DDD - Il modello di dominio anemico è un antipattern? Vuoi usare modelli di dominio avanzati? [chiuso]

Il modello di dominio anemico è stato criticato molto tempo fa da Evans e Fowler , poiché apparentemente va contro i principi orientati agli oggetti, ecc. La comunità DDD è chiaramente allineata con queste affermazioni.

Tuttavia, negli ultimi anni ci sono state voci in disaccordo che affermano che non è affatto un antipasto e che è un esempio dei seguenti principi SOLIDI.

Lavoro da tanti anni con Spring Framework. Ogni progetto in ogni azienda ha sempre avuto un livello di servizio contenente la logica di business, utilizzando repository che operano su modelli anemici (entità JPA). Inoltre, la maggior parte dei campioni, anche quelli ufficiali dei ragazzi di Spring, mostrano questo modo di lavorare.

Le mie domande sono: il modello di dominio anemico è ancora considerato un antipattern? Abbiamo fatto tutti cose sbagliate (riguardo al DDD)? Non pensi che avere modelli Rich Domain violi i principi SOLIDI?

ADM è un buon modello per una soluzione di servizi distribuiti come microservizi. Si adatta a molti dei casi aziendali di oggi basati sul web.

Considera se abbiamo un oggetto Dominio ordine. Con un approccio OOP aggiungeremmo Order.Purchase () Order.Cancel () ecc. Funzionerebbe bene in un'app desktop, dove conserviamo gli ordini in memoria e facciamo più cose nella stessa istanza.

Ma se abbiamo un sistema distribuito, con programmi che riguardano solo una cosa, ovvero accedere a un elenco di ordini e acquistarli a turno, oppure ottenere un elenco di ordini e cancellarli a turno, avere entrambi i metodi sullo stesso oggetto non fa senso. Dovremmo avere due domini o contesti limitati:

PurchaseSystemOrder.Purchase()

e

CancelSystemOrder.Cancel();

L'unica cosa che questi oggetti condividono sarebbe la struttura dei dati delle proprietà.

Man mano che aggiungi sempre più microservizi, finisci con dozzine di tipi di ordine. Non ha più senso parlare di un Ordine come oggetto Dominio, anche se è lo stesso ordine concettuale che viene elaborato da tutti questi sistemi.

Ha molto più senso avere un modello Anemic, Order, che incapsula solo i dati e rinominare i servizi di conseguenza:

PurchaseService.Purchase(Order order)

Ora possiamo parlare di nuovo di Order e possiamo aggiungere qualsiasi nuovo servizio che pensiamo di elaborare, senza influire sugli altri servizi attualmente distribuiti.

Fowler e Co provengono da un background di sistema monolitico, nel loro mondo un approccio ADM significherebbe un'unica app con tutti questi servizi separati istanziati in memoria e OrderDTO viene fatto circolare e mutato. Questo sarebbe molto peggio che mettere i metodi su un ricco modello di Ordine.

Ma in un sistema distribuito, ci sono molti programmi, ognuno richiede solo un singolo metodo Ordine e lo esegue su più ordini, caricandoli ciascuno, eseguendo il metodo e quindi scartandolo. Richiede solo un singolo servizio e un flusso di oggetti dati.

Il popolamento completo di un modello completo, preoccuparsi dei requisiti e delle dipendenze di tutti i metodi solo per chiamarne uno singolo e scartare l'oggetto quasi immediatamente è inutile.

Inoltre, una modifica a uno dei metodi richiederebbe l'aggiornamento di tutti i componenti distribuiti poiché dipendono tutti dal modello Rich per la loro logica.

Non ho spazio nella mia base di codice per le cose di cui non hanno bisogno

SOLID e DDD sono ortogonali tra loro, il che significa che stanno davvero andando in direzioni diverse l'una dall'altra. Non dovresti dire che uno è usato ad esclusione dell'altro, poiché possono e dovrebbero probabilmente esistere insieme nella stessa base di codice.

I modelli di dominio anemico diventano un modello anti-pattern solo quando il dominio problematico ha un comportamento elevato e si dispone di centinaia di metodi di servizio con molta logica o dipendenze incollate in cui i metodi del livello di servizio devono chiamare altri metodi del livello di servizio per eseguire qualsiasi operazione.

DDD è un paradigma eccellente per i micro-servizi grazie al concetto di contesto limitato .

Fai attenzione alla tentazione di vedere il codice dell'infrastruttura come parte del tuo dominio. Il codice dell'infrastruttura è tutto ciò che non è stato scritto dall'utente o è associato a un framework o una libreria che interagisce con un sistema di terze parti. Connessioni al database, mailer SMTP, librerie ORM, tempi di esecuzione del server delle applicazioni, tutto ciò che è infrastruttura e non dovresti includerlo o dipenderlo nel tuo dominio se puoi evitarlo.

I principi SOLID sono un insieme di concetti OOP generici che è possibile utilizzare per creare un codice OOP migliore. È possibile scrivere una buona base di codici DDD utilizzandoli.

Un dominio ricco è bello se fatto bene. Un incubo quando no. Un dominio anemico è sempre negativo. Ma è un tipo familiare di male.

Se un dominio anemico è tutto ciò che desideri, hai scelto la lingua sbagliata quando hai scelto una lingua per scopi generici. Le lingue di quarta generazione sono specializzate in un uso specifico. Se l'anemico è abbastanza buono usarli ti avrebbe semplificato la vita.

Molti framework si diffondono nello spazio linguistico fino a quando non è più possibile pubblicizzare il lavoro come lavoro java. È un lavoro Java / Spring. Quello che stanno facendo, oltre a farti dipendere da loro, è trasformare una lingua per scopi generici in una forma bastarda di una lingua di quarta generazione.

È una buona pratica o un modello anti? Bene, il tuo capo si preoccupa solo se puoi assumere persone per lavorare sulla base di codice. Quindi, se dobbiamo fingere di usare un linguaggio generico per assumere persone, lo faremo.

Se stai bene, allora va bene. Di certo non sei l'unico.

Ma non dirmi che è così che deve essere. Non dirmi che sta facendo qualcosa per me più di quanto non sia. So vivere senza di essa. So come espellerlo, quindi solo poche cose dipendono da esso. Se mi stai chiedendo di arrendermi e lasciare che prenda il controllo di tutto solo perché combatterlo è troppo difficile, sì, penso che sia male.

Non ho spazio nella mia base di codice per cose di cui non ha bisogno.

Per quanto riguarda SOLID e gli altri principi di progettazione, posso seguire ampiamente quelli anche in un dominio anemico. Non seguirli causa un diverso tipo di problema.