Modello di dominio anemico e modello di dominio in un semplice progetto basato sul dominio

Question

Recentemente ho letto un post su "The Anemic Domain Model Pattern" che ha attirato la mia attenzione. Leggendo questo ho scoperto che la descrizione del modello di dominio anemico si applicava a molti dei progetti su cui ho lavorato e che ho costruito. Non ho mai pensato a questo come a una cattiva decisione di progettazione, in quanto mi sembrava molto naturale. Ho pensato che nel caso in cui il domain model fosse leggero e non molto complesso, il moniker del modello di dominio Anemic si adattava abbastanza bene. Perché aggiungere complessità al modello di dominio in cui non è necessario che sia così che il titolo di "Anemic Domain Model" non descriva correttamente il codice?

Domanda: A che punto l'imbottitura di più complessità del codice nel livello di servizio/applicazione diventa non corretta per esporre invece la complessità degli oggetti entità? Sono tutto per avere una proprietà "Totale" su un'entità in cui internamente è possibile calcolare il valore per il totale. Non sto facendo in modo che Entity comunichi direttamente con altri widget per determinare il risultato di una delle sue proprietà. Quindi il concetto di un modello di dominio anemico è un anti-modello o una buona separazione delle preoccupazioni? Il titolo Anemic Domain Model è sempre una brutta cosa?

Solo curioso di sapere quali pensieri delle altre persone erano su questo modello (anti) di progettazione.

Answer 1

La questione chiave è quella di chiedere perché è il modello di dominio anemico?

• quasi totale assenza di logica di business, come in un programma che è in primo luogo un assemblaggio di CRUD screens?
• Architettura orientata ai servizi in cui gli "oggetti dominio" sono in effetti strutture semplici data transfer objects?
• Considerazioni politiche o pragmatiche come la proprietà del codice o la compatibilità forward/backward che ostacolano eccessivamente il refactoring?
• Applicazione della progettazione procedurale/relazionale in un linguaggio orientato agli oggetti altrimenti?

In ogni caso, se dovessi scegliere una semplice regola empirica per il confine tra logica modello di dominio e logica di servizio, sarebbe che interagendo con oggetti correlati va bene all'interno del dominio, durante l'accesso al "fuori mondo "(interfaccia utente, servizi Web, ecc.) probabilmente non appartiene al modello di dominio.

Answer 2

Se il dominio è leggero (leggi: non complesso), l'approccio consigliato è quello di utilizzare un oggetto di tipo ActiveRecord semplice nel livello del dominio principale. Di solito una mappatura uno-a-uno tra le tabelle DB e gli oggetti del dominio e qui non c'è un sacco di "logica". La tua app mescola solo i record tra il database e l'interfaccia utente e consente semplici operazioni CRUD.

Per domini complessi, si costruisce un modello di dominio di base in cui alcuni oggetti finiscono per mappare le tabelle DB e alcuni probabilmente no e rappresentano altri concetti nel proprio dominio oltre a semplici dati. La logica per l'applicazione deve essere all'interno degli oggetti quando appropriato o all'interno degli oggetti di servizio se richiede il coordinamento tra più oggetti di dominio.

L'anti-pattern del modello di dominio anemico si applica a quando si dispone di un dominio complesso ma invece di mettere appropriatamente qualche logica negli oggetti di dominio e in alcuni servizi logici, si mette TUTTA (o quasi) la logica esterna al core oggetti di dominio.

La differenza fondamentale qui è dove si inserisce la logica. Se non si dispone di molto, ovviamente gli oggetti del dominio non assomiglieranno a semplici contenitori di dati. Se hai una logica complicata, non limitarti a estrarre TUTTI gli oggetti di dominio ma a separarli in modo appropriato tra gli oggetti del dominio e i servizi di dominio.

Answer 3

Buongiorno!

Se si mette la logica fuori dagli oggetti del dominio, si perde completamente uno dei concetti OO principali: incapsulamento (o occultamento dei dati).

AOP lo rende fino a un certo grado, ma dopo tutto, uno dei principali concetti di orientamento all'oggetto è sparito.

saluti, Stefan