Evitando modello di dominio anemico - un esempio reale

Question

Sto cercando di capire i modelli di dominio anemico e perché sono presumibilmente un anti-modello.

Ecco un esempio reale.

Ho una classe Employee, che ha un sacco di proprietà - nome, sesso, nome utente, ecc

public class Employee
{
    public string Name { get; set; }
    public string Gender { get; set; }
    public string Username { get; set; }
    // Etc.. mostly getters and setters
}

Avanti abbiamo un sistema che coinvolge a rotazione le chiamate in arrivo e richieste di informazioni del sito web (noto come 'porta') in modo uniforme tra personale di vendita. Questo sistema è molto complesso in quanto si tratta di andata e robining indagini, il controllo per le vacanze, le preferenze dei dipendenti ecc Quindi questo sistema è attualmente separato fuori in un servizio:. EmployeeLeadRotationService

public class EmployeeLeadRotationService : IEmployeeLeadRotationService
{
     private IEmployeeRepository _employeeRepository;
     // ...plus lots of other injected repositories and services

     public void SelectEmployee(ILead lead)
     {
         // Etc. lots of complex logic
     }
}

Poi, sul retro del nostro modulo di richiesta web abbiamo codice come questo:

public void SubmitForm()
{
    var lead = CreateLeadFromFormInput();

    var selectedEmployee = Kernel.Get<IEmployeeLeadRotationService>()
                                 .SelectEmployee(lead);

    Response.Write(employee.Name + " will handle your enquiry. Thanks.");
}

Non realmente incontrato molti problemi con questo approccio, ma presumibilmente questo è qualcosa che avrei dovuto scappare a gambe levate dal perché si tratta di un Anemic Domain Model .

Ma per me la sua non è chiaro dove la logica nel servizio di rotazione di piombo dovrebbe andare. Dovrebbe andare in testa? Dovrebbe andare in dipendente?

Che dire di tutti i repository iniettato etc che il servizio di rotazione richiede - come avrebbero essere iniettati nel dipendente, dato che la maggior parte del tempo quando si tratta di un dipendente non abbiamo bisogno uno di questi repository

Answer 1

In questo caso ciò non costituisce un modello di dominio anemico. Un anemico Domain Model è specificamente sulla convalida e trasformando gli oggetti . Così un esempio di questo sarebbe se una funzione esterna effettivamente cambiato lo stato dei dipendenti o aggiornato i propri dati.

ciò che sta accadendo in questo caso è che si sta assumendo tutti i dipendenti e di fare una selezione di uno di loro in base alla loro informazioni. E 'bene avere un oggetto separato che prende in esame gli altri e prende decisioni per quanto riguarda ciò che trova. Può comunque tentare di avere un oggetto che viene utilizzato per la transizione di un oggetto da uno stato ad un altro.

Un esempio di un modello di dominio anemico nel tuo caso sarebbe quello di avere un metodo esterno

updateHours(Employee emp) // updates the working hours for the employee

che prende un oggetto Employee e aggiorna le sue ore lavorate per settimana, facendo in modo che le bandiere sono sollevate se le ore superano un certo limite. Il problema di questo è che gli oggetti se hai solo dei dipendenti, allora non si ha conoscenza di come modificare le loro ore entro i limiti corretti. In questo caso il modo di affrontare sarebbe spostare il metodo updateHours nella classe Employee. Questo è il punto cruciale del modello anti Anemic Domain Model.

Answer 2

Credo che il disegno è bene qui. Come sapete, il modello di dominio anemico anti-modello è una reazione contro la tendenza di evitare qualsiasi comportamento codificato in oggetti di dominio. Ma al contrario non significa tutti il comportamento relativo ad un oggetto di dominio deve essere incapsulato da quell'oggetto.

Come regola empirica, comportamento che è intrinsicly legata all'oggetto dominio ed è interamente definita in termini di tale istanza oggetto dominio può essere incluso nel dominio oggetto. In caso contrario, per mantenere le responsabilità chiare, è meglio metterlo esternamente in un collaboratore / servizio come avete fatto.

Answer 3

E 'tutto nella tua testa -. Consideriamo il servizio di rotazione per essere una parte del modello di dominio e le dissolve problema

La rotazione ha bisogno di mantenere informazioni su molti dipendenti, in modo che non appartiene né piombo, né di qualsiasi oggetto dipendente singolo. Lo fa per meritare di essere un oggetto di dominio in sé.

Basta rinominare "RotationService" per qualcosa come "Organization.UserSupportDepartment" rende evidente.

Answer 4

Se il modello di dominio contiene solo i ruoli e le cose, non le attività come il comportamento, allora è anemico. Comunque, sto parlando di comportamento per quanto riguarda un modello di non è un oggetto . Parlo della differenza tra di loro in un'altra risposta ... https://stackoverflow.com/a/31780937/116442

Dalla tua domanda, si rompono le mie prime regole analisi di modellazione due domini: -

1. Comportamento modellata come attività (registrate) sono al centro di un modello di dominio. Aggiungi loro per primi.
2. attività Domain Model come classi, non i metodi.

vorrei aggiungere un'attività "Inquiry" per il modello. Con esso il modello ha comportamento, e può unire e lavorare come gruppo di oggetti senza un controllo esterno o uno script.