Trattare con un modello di dominio anemico

Question

Stavo cercando di separare il mio DAL dal mio livello aziendale e, nel farlo, ho deciso di evitare qualsiasi approccio ActiveRecord e optare per un approccio DataMapper. In altre parole, i miei oggetti di dominio non si occuperebbero di perseverare. Nel fare ciò, mi sembra di invadere il "modello di dominio anemico" anti-modello. Ad esempio, una delle entità nel mio programma è un'organizzazione.

Un'organizzazione è rappresentata come qualcosa del genere:

class Organization {
    private $orgId;
    private $orgName;

    // getters and setters
}

Quindi sostanzialmente questa organizzazione non fa altro che agire come "bag" (come dice Martin Fowler) per alcuni dati. Nel mondo PHP non è altro che un array glorificato. Non vi è alcun comportamento associato ad esso.

E comportamento nel programma, ho aderito al "livello di servizio" classe come un OrganizationService che serve principalmente come intermediario tra questi oggetti e il DAL.

Oltre ai potenziali problemi di ridimensionamento con PHP (ho altri motivi per cui insisto per "insaccare" i miei dati in questi oggetti), questo approccio è totalmente off?

Come gestisci i tuoi modelli di dominio in queste situazioni? Forse un'organizzazione non fa parte del mio dominio in primo luogo?

Answer 1

beh, sembra così all'inizio, ma quando rifatterai di più il tuo codice, otterrai un comportamento per la tua classe di organizzazione ...

un esempio a cui potrei pensare ora è se hai persone (dipendenti), potresti volerle associare all'organizzazione. quindi, potresti avere un metodo AssociateEmployee (impiegato dell'utente) che potrebbe trovare il suo posto nella classe della tua organizzazione.

Oppure potresti cambiare la posizione dell'azienda, invece di impostare parametri come indirizzo, città, stato in tre passaggi, potresti aggiungere il metodo ChangeLocation (via, città, stato) .

Procedi passo dopo passo, quando trovi del codice nel tuo BL / service layer che sembra appartenere al dominio, spostalo verso il basso nel dominio. Se leggi Fowler, lo otterrai molto presto quando lo vedrai nel tuo codice.

Answer 2

Potrebbe essere solo anemico ora?

Ad esempio, una volta stavo sviluppando un sito di registrazione per riunioni / conferenze. È iniziato con un solo incontro.

C'era ancora una lezione e solo un'istanza, ma l'anno successivo tenemmo la conferenza, che fu ampliata e furono aggiunte nuove proprietà (per tenere due riunioni back-to-back), quindi chiaramente non era proprio sviluppato ancora, dal momento che abbiamo aggiunto gruppi di incontro che potrebbero contenere più incontri.

Quindi penso che sia importante tenere presente che i domini cambiano nel tempo e il tuo modello potrebbe finire per essere refactored, quindi anche se potresti pensare che sia anemico, potrebbe essere solo un po 'troppo lungimirante (come la tua classe di organizzazione inizierà a ottenere alcune impostazioni, regole o preferenze o qualcosa del genere).

Answer 3

Potresti anche considerare che se non hai molte regole di business, o il dominio non è così complesso, DDD potrebbe essere troppo sovraccarico per te. DDD è un'eccellente soluzione per domini di grandi dimensioni e complicati, ma è un sacco di sovraccarico e complessità se si stanno semplicemente eseguendo dati in entrata, in uscita. DDD è più difficile da progettare e aggiunge intrinsecamente complessità, quindi per giustificarla, la complessità del dominio problematico dovrebbe superare quella.

Questo è tutto ciò che aggiungerei a zappan ed epitka.

Answer 4

La tua entità non è anemica perché stai assumendo una reposnsibilità che non dovrebbe essere lì per cominciare. Persistere e recuperare entità è la responsabilità dei repository. Davvero il tuo comportamento dovrebbe essere nelle tue entità non in un livello di servizio. Ma spiegare ciò che va dove va ben oltre la semplice risposta. DDD di Eric Evans è un buon punto di partenza.