DDD - Il pattern anemico del modello di dominio è anti? Dovremmo utilizzare modelli di dominio ricchi? [chiuso]

ADM è un buon modello per una soluzione di servizi distribuiti come un microservizio. Si adatta a molti degli attuali casi aziendali basati sul Web.

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

Ma se abbiamo un sistema distribuito, con programmi che includono solo una cosa, cioè accedere a un elenco di ordini e acquistarne uno a turno, o ottenere un elenco di ordini e annullare ciascuno a turno, avendo entrambi i metodi sullo stesso l'oggetto non ha senso Dovremmo avere due domini o contesti limitati:

PurchaseSystemOrder.Purchase()

e

CancelSystemOrder.Cancel();

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

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

È molto più sensato avere un modello anemico, Ordine, che incapsula solo i dati e rinominare i servizi di conseguenza:

PurchaseService.Purchase(Order order)

Ora possiamo parlare di nuovo dell'Ordine e possiamo aggiungere qualsiasi nuovo servizio che pensiamo di elaborare, senza influire sugli altri servizi attualmente implementati.

Fowler e Co provengono da un background di sistema monolito, nel loro mondo un approccio ADM significherebbe una singola app con tutti questi servizi separati istanziati in memoria e OrderDTO che viene passato in giro e mutato. Questo sarebbe molto peggio di mettere i metodi su un ricco modello di ordine.

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

Compilare completamente un modello ricco, preoccuparsi dei requisiti e delle dipendenze di tutti i metodi solo per chiamarne uno singolo e poi scartare l'oggetto quasi immediatamente è inutile.

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

Non ho spazio nella mia base di codice (s) per cose di cui non hanno bisogno

SOLID e DDD sono ortogonali tra loro, il che significa che stanno davvero andando in direzioni diverse l'uno dall'altro. Non dovresti dire che si è abituati all'esclusione dell'altro, dal momento che possono e dovrebbero probabilmente esistere insieme nella stessa base di codice.

I modelli di dominio anemico diventano un anti-pattern solo quando il tuo dominio problematico ha un sacco di comportamenti e hai centinaia di metodi di servizio con molta logica o dipendenze copiate dove i metodi del livello di servizio devono chiamare altri metodi del livello di servizio per ottenere qualcosa fatto.

DDD è un eccellente paradigma per i micro-servizi a causa del 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 hai scritto tu stesso o qualcosa che è accoppiato 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 questo è infrastruttura e non dovresti includere o dipendere da esso nel tuo dominio se puoi evitarlo.

I principi SOLID sono un insieme di concetti OOP di uso generale che è possibile utilizzare per migliorare il codice OOP. Puoi scrivere una buona base di codice DDD usando loro.

Un dominio ricco è bello se fatto bene. Un incubo quando no. Un dominio anemico è sempre cattivo. Ma è un tipo familiare e constrongvole di cattivo.

Se un dominio anemico è tutto ciò che desideri, scegli la lingua sbagliata quando scegli una lingua generica. Le lingue di quarta generazione si specializzano intorno a un uso specifico. Se l'anemia è abbastanza buona usarli avrebbe reso la vita più facile.

Molti framework avviano la loro strada nello spazio linguistico fino a quando non puoi più pubblicizzare il lavoro come un lavoro java. È un lavoro Java / Spring. Quello che stanno facendo, oltre a farti dipendere da loro, è trasformare un linguaggio generico in una forma bastarda di una lingua di quarta generazione.

È una buona pratica o un modello anti? Beh, per la maggior parte del tuo capo ti preoccupi solo se puoi assumere persone per lavorare sulla base di codice. Quindi, se dobbiamo fingere di usare una lingua generica per assumere persone, lo faremo.

Se stai bene allora va bene. Sicuramente 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 come vivere senza di essa. So come spingerlo in modo che solo alcune cose dipendano da questo. Se mi stai chiedendo di arrendermi e lasciare che tutto subisca tutto solo perché combattere è troppo difficile, allora penso che sia brutto.

Non ho spazio nella mia base di codice per cose che non è necessario.

Come per SOLID e gli altri principi di progettazione, posso seguirli in gran parte anche in un dominio anemico. Non seguirli causa un diverso tipo di problema.