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?

score 18 · Accepted Answer · answered Sep 10 '13 at 09:14

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.

score 7 · Answer 2 · answered Jul 24 '12 at 12:45

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.

score 2 · Answer 3 · answered Nov 23 '11 at 16:19

2

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.

answered Nov 23 '11 at 16:19

Ed I

7,008
3
41
50

Are you saying that the example I gave above is a good idea or that it is "allowable" and common in DDD? – Asher Nov 24 '11 at 07:05
1

It's a fine idea. It makes it very clear that the accounting context doesn't differentiate between salaried employees as far as any business logic is concerned. You just have to feel confident that the accounting context will never need to differentiate them. – Ed I Nov 24 '11 at 16:38

score 1 · Answer 4 · answered Nov 24 '11 at 10:07

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 :)

Entities across bounded contexts in Domain-Driven Design

4 Answers4

Linked