Entidades en contextos delimitados en Diseño controlado por dominio

Question

Estoy tratando de comprender cómo funcionan las entidades en contextos acotados múltiples.

Dado un empleado de una empresa. En (por ejemplo) el contexto de Recursos humanos, esta persona tiene un nombre, un apellido, una dirección, un número de referencia de sueldo y una cuenta bancaria. Pero en el contexto de Contabilidad, todo lo relevante es el número de referencia salarial y la cuenta bancaria.

¿Tiene una entidad de empleado en el contexto de recursos humanos y un valor de tipo (por ejemplo, SalariedEmployee) en el contexto de contabilidad?

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

SalariedEmployee clase (??): Empleado del valor de tipo

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

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

¿El HRService en el contexto acotado devolver esta información? ¿O usas la clase Empleado en ambos contextos?

Answer 1

Supongo que no usaría la misma entidad en ambos contextos. Se supone que deben estar limitados. ¿Qué pasa si tengo que cambiar mi clase de empleado por las necesidades de un contexto? ... el "supuesto contexto delimitado" ya no está limitado.

Yo usaría un objeto de valor. El truco es definir correctamente el objeto de valor. Veo que son equivalentes al objeto "Tipos de datos", como un entero es un número entero. Esto es cuestionable por supuesto (int16, int32 ...). Pero supongamos que es el caso. ¿El empleado es un buen candidato para un objeto de valor? .... No lo creo: (... Es posible que no necesite el mismo conjunto de información para el empleado en un contexto delimitado. En otro nombre, la información de identificación del empleado es una mejor candidato (primer nombre, apellido, segundo nombre ...) Esto podría reutilizarlo en contexto acotado.

Ahora, ¿la capa de servicio debería devolver este objeto de valor? ... Personnaly Yo no lo haría. Preferiría tener esto reutilización define en mis repositorios. asignaciones de uso compartido en Nhibernate o compartir la misma clase de proyección/asignador.

Espero que esto ayude :)

Answer 2

Si se necesita más de un contexto, definitivamente algunas cosas se pueden modelar como una entidad en algunos contextos y un objeto de valor en otro. Traducir de una entidad a un objeto de valor suele ser sencillo, pero de un objeto de valor a una entidad puede no ser tan sencillo. De Domain Driven Design, p. 337:

El mecanismo de traducción no está controlado por el modelo. No está en el contexto delimitado. (Es parte de la frontera en sí, que se discuten en mapa de contexto.)

Si el contexto de Recursos Humanos siempre tiene que hacer una pregunta acerca de un empleado en particular el contexto de Contabilidad, se convertiría en una pregunta confusa .

Answer 3

Si están estrictamente separados, les haría estrictamente separados. Dos clases diferentes en diferentes espacios de nombres. Cada uno tiene diferentes atributos.

Si HR crea un HRM.Employee, se podría generar un evento que la Contabilidad recoja y cree un Accounting.Employee.

Answer 4

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

acotada contextos de son componentes autónomos, con sus propios modelos de dominio y su propio idioma en todas partes. No deberían tener ninguna dependencia el uno del otro en tiempo de ejecución y deberían ser capaces de ejecutarse de forma aislada. Sin embargo, son parte del mismo sistema general y no necesitan intercambiar datos entre sí.

Si va a implementar la CQRS pattern en un contexto limitado, usted debe utilizar los eventos para este tipo de comunicación: su contexto acotado puede responder a eventos que son criados fuera del contexto acotado y su contexto delimitado pueden publicar eventos que otros contextos delimitados pueden suscribirse. Los eventos (mensajes asincrónicos unidireccionales que publican información sobre algo que ya sucedió) le permiten mantener el acoplamiento flexible entre sus contextos delimitados.