Entità in contesti limitati nella progettazione guidata dal dominio

Question

Sto cercando di capire come le entità operano in più contesti limitati.

Dato un impiegato di una società. In (ad esempio) il contesto Risorse umane, questa persona ha un nome, cognome, indirizzo, numero di riferimento di stipendio e conto bancario. Ma nel contesto Contabilità tutto ciò che è rilevante è il numero di riferimento del salario e il conto bancario.

Hai un'entità dipendente nel contesto delle risorse umane e un valore di tipo (ad esempio SalariedEmployee) nel contesto Contabilità?

class Employee 
{ 
    public BankAccount BankAcountDetails { get; set; } 
    public string FullName { get; set; } 
    public Address ResidentialAddress { get; set; } 
    public string SalaryRef { get; set; } 
} 

SalariedEmployee classe (??): Dipendente value-type

class SalariedEmployee 
{ 
    public SalariedEmployee(string salaryRef, BankAccount bankAcountDetails) 
    { 
     ... 
    } 

    public string SalaryRef { get; } 
    public BankAccount BankAcountDetails { get; } 
} 

Fa il HRService nel contesto limitato restituire queste informazioni? O usi la classe Employee in entrambi i contesti?

Answer 1

Suppongo che non utilizzerei la stessa entità in entrambi i contesti. Dovrebbero essere limitati. Cosa succede se devo cambiare la mia classe di dipendenti per le esigenze di un contesto? ... il "presunto contesto limitato" non è più limitato.

Vorrei utilizzare un oggetto valore. Il trucco è definire correttamente l'oggetto valore. Vedo che sono equivalenti all'oggetto "Tipi di dati", come un intero è un numero intero. Ovviamente questo è sfidabile (int16, int32 ...). Ma supponiamo che sia così. Il Dipendente è un buon candidato per un oggetto di valore? .... Io non la penso così: (... Potrebbe non essere necessario lo stesso insieme di informazioni per il Dipendente in un contesto limitato. In un altro nome le informazioni di identificazione del dipendente sono candidato migliore (nome, cognome, nome-chiave ...) Questo è possibile riutilizzare in un contesto limitato

Ora il livello di servizio deve restituire questo valore oggetto? ... Personnaly Non lo farei Preferirei avere questo riutilizzabilità definito nel mio repository. mappature di condivisione in NHibernate o la condivisione della stessa classe di proiezione/mapper.

Spero che questo aiuti :)

Answer 2

Se è necessario più di un contesto, alcune cose possono sicuramente essere modellate come entità in alcuni contesti e un oggetto valore in un'altra. La traduzione da un'entità a un oggetto valore è in genere semplice, ma da un oggetto valore a un'entità potrebbe non essere così semplice. Da Domain Driven Design, p. 337:

Il meccanismo di traduzione non è guidato dal modello. Non è in il contesto limitato. (E 'parte del confine stesso, che saranno discussi in un contesto del programma.)

Se il contesto Risorse Umane mai ha bisogno di una domanda su un singolo lavoratore contesto contabile, sarebbe diventata una questione di confusione .

Answer 3

Se sono rigorosamente separati, io li avrebbe fatti rigorosamente separati. Due classi diverse in diversi spazi dei nomi. Ognuno ha attributi diversi.

Se HR crea un HRM.Employee, è possibile che venga generato un evento che la Contabilità preleva e crea un Accounting.Employee.

Answer 4

Da http://msdn.microsoft.com/en-us/library/jj554200.aspx:

Bounded contesti sono componenti autonome, con i propri modelli di dominio e la propria lingua onnipresente. Non dovrebbero avere alcuna dipendenza reciproca in fase di esecuzione e dovrebbero essere in grado di funzionare in isolamento. Tuttavia, fanno parte dello stesso sistema generale e devono scambiarsi dati tra loro.

Se si implementa il CQRS pattern in un contesto limitato, si consiglia di utilizzare gli eventi per questo tipo di comunicazione: vostro contesto delimitato può rispondere a eventi generati al di fuori del contesto limitato, e il vostro contesto delimitata può pubblicare eventi a cui altri contesti limitati possono iscriversi. Eventi (messaggi unidirezionali asincroni che pubblicano informazioni su qualcosa che è già accaduto), ti permettono di mantenere l'accoppiamento libero tra i tuoi contesti limitati.