DDD Bounded Context "integration"

Question

We're trying to figure out the separated bounded context integration for a scenario.

Say one context is the Document Core Bounded Context (BC) and has a Document Entity, with an Author. Using the IdentityAccessContext BC as in the Implementing DDD book which separates Users, Groups, and Roles into their own context makes sense.

The problem that is occurring is when considering fetching a list of say 100+ Documents.

Say the Document Core BC has it's own Entity to mark the Author of a Document.

public class Author
{
    long Id; // Same as UserId
    long Document;  
}

And then the Identity BC has a User with relevant info.

public class User
{
    long Id;
    string FullName;
}

When fetching a List of Documents, how is the information from the IdentityAccess BC supposed to be retrieved into/with the Document Author for displaying (Full Name for example)?

There seem to be a couple alternatives:

1. Perhaps a Anti-corruption Layer which fetches data from both tables?
2. Duplicate the user's full name across the two BC's?

Neither feel quite right, since #1 requires joining data (at some level) from 2 BC's, while #2 requires potentially updating several BC's when changing the user's name.

What can be done about this? (Using C#, MVC, NHibernate if that matters) Clearly fetching a list of objects and later fetching e.g. the Author's name and additional data later isn't realistic.

When looking at the BC integration, however, given the 3 options mentioned in the book RPC, Domain Events, and RESTful service integration, at least the latter 2 don't make sense in this case where the application is MVC, and it directly uses the 2 BC's as class libraries and they both use the same database. Updating Users information can be done directly from MVC through the Identity BC's Application Services. The database and BC can be changed as/if needed.

Answer 1

Instead of integrating these bounded contexts you'll probably want to compose them. Have a look at the relevant section under the 'Application' chapter in the implementing DDD book.

One approach is to create an application service that accesses both bounded contexts and creates a Document DTO containing the information from both BC's.

You can even go a step further and create a third bounded context for it, and use well known BC integration techniques in order to keep this new BC in sync (messaging, nightly batch, etc.). As Vaughn Vernon points out in his book, this would probably result in an anemic domain model in this new BC.

Answer 2

Some solutions you may be interested:

A. using redundant attributes in document bounded context. like

public class Author {
    long Id; // Same as UserId
    string fullname://redundant
    long Document;  
}

But this one is not flexible and the model has to change if the query requirment changes.

B. Domain model is not good at querying, if you're familiar with CQRS, a better solution would be build an seperate query component.