Entities across bounded contexts in Domain-Driven Design

Question

I am trying to understand how entities operate in multiple bounded contexts.

Given an Employee of a Company. In (for example) the Human Resources context, this person has a name, surname, address, salary reference number, and bank account. But in the Accounting context all that is relevant is the salary reference number and bank account.

Do you have an Employee entity in the HR context and a Value-Type (e.g. SalariedEmployee) in the Accounting context?

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

SalariedEmployee class (??) : Employee's value-type

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

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

Does the HRService in the bounded context return this information? Or do you use the Employee class in both contexts?

Answer 1

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

Bounded contexts are autonomous components, with their own domain models and their own ubiquitous language. They should not have any dependencies on each other at run time and should be capable of running in isolation.However they are a part of the same overall system and do need to exchange data with one another.

If you are implementing the CQRS pattern in a bounded context, you should use events for this type of communication: your bounded context can respond to events that are raised outside of the bounded context, and your bounded context can publish events that other bounded contexts may subscribe to. Events (one-way, asynchronous messages that publish information about something that has already happened), enable you to maintain the loose coupling between your bounded contexts.

Answer 2

If they are strictly separate, I would make them strictly separate. Two different classes in different namespaces. Each have different attributes.

If HR creates an HRM.Employee, an event could be raised that Accounting picks up and creates an Accounting.Employee.

Answer 3

If more than one context is necessary, definitely some things can be modeled as an entity in some contexts and a value object in another. Translating from an entity to a value object is usually straightforward, but from a value object to an entity may not be so straightforward. From Domain Driven Design, p. 337:

The translation mechanism is not driven by the model. It is not in the bounded context. (It is part of the boundary itself, which will be discussed in context map.)

If the Human Resources context ever needs to ask the Accounting context a question about a particular employee, it would become a confusing question.

Answer 4

I guess I would not use the same entity in both context. They are supposed to be bounded. What if I have to change my employee class for the needs of one context?... the "supposed to be bounded context" is not that bounded anymore.

I would use a value object. The trick is to define properly the value object. I see those are equivalent to "Data Types" object, like an integer is an integer. This is challengeable of course (int16,int32...). But let's assume it is the case. Is Employee a good candidate for a value object?.... I do not think so :(... You might not need the same set of information for Employee in bounded context. In another name the identification information of the employee is a better candidate (firstname, lastname, middlename...) This you could reuse in bounded context.

Now should the service layer return this value object?... Personnaly I would not do it. I would prefer to have this reusability defined in my repositories. Sharing mappings in Nhibernate or sharing the same projection/mapper class.

Hope this helps :)