DDD - How to design associations between different bounded contexts

Question

I have setup a domain project which is being populated with an ORM. The domain contains of different aggregates each with its own root object. My question is how properties that cross the aggregate boundries should be treated?

• Should these properties simply ignore the boundries so that a domain object in bounded context A has a reference to an object in context B?
• Or, should there be no direct link from context A to B and does the object in context A have an "int ContextBId" property that can be used to get the domain object from B through the B aggregate root?
• Or ...

An example:
Context A = Users
Context B = Games

Inside the Users context there is an object UserOwnedGames. This object has a property User which is a reference to an object in the same Users context. The object also has a property to a Game which is obviously not in the Users but rather in the Games context.

How would (or should?) this relation look like? It's clear in the database (ie 2 foreign keys) but what should the code look like?

Bivins

Answer 1

It sounds like your User context also needs a Game entity. Note however that this is not necessarily the same Game entity which is the root of the Game context. These two bounded contexts may have different ideas of what a Game is, and what properties it has. Only the identity ties the two Game objects together.

User Context
{
    Aggregate Root User
    {
        Identity;
        Name;
        OwnedGames : List of Game value entities
    }

    Value Entity Game
    {
        Identity;
        Name;
    }
}

Game Context
{
    Aggregate Root Game
    {
        Identity;
        Name;
        Owner : User value entity
        HighScore : int
        TimesPlayed : int
        ... A whole bunch of other properties which are not relevant in the User context
    }

    Value Entity User
    {
        Identity;
        Name;
        // No OwnedGames property, in this context we don't care about what other games the user owns.
    }
}

Salyers

Very interesting concept.. I never even thought about having multiple versions of the same thing. – Bivins

In DDD, there's no global, definitive notion of what something "is", a "thing" is only a "thing" in some context. – Salyers

So how do you handle synchronizing references to the same property across contexts? Say I update the Name property of User in the User Context, how do I get it to update the Name property of User in the Game Context? Do you use a getter to reach across the to other context when it is requested? Or do you have some kind of method that synchronizes the two? – Noam

Hi @Balrog30, that would be where domain events come in. See this slideshare – Salyers

Hi @nbering, nice question! Did you got an answer for that ? – Technicolor

Answer 2

You should avoid DB references across BCs - you shouldn't try to ensure referential integrity between aggregates from different BCs (transactions). Ideally, transaction should live only inside single aggregate, not even BC.

Better use simple value objects for IDs - UserId and GameId - and assign them to entity if needed. This way those "remote" entities are completely detached so you don't have to worry about their connection. Sync could be implemented using messaging platform.

If you have spare time read these valuable articles (by Vaughn Vernon):

• http://dddcommunity.org/wp-content/uploads/files/pdf_articles/Vernon_2011_1.pdf
• http://dddcommunity.org/wp-content/uploads/files/pdf_articles/Vernon_2011_2.pdf
• http://dddcommunity.org/wp-content/uploads/files/pdf_articles/Vernon_2011_3.pdf

Rematch

Hi, but if i want to enforce Data Integrity on the database level – Gillie

Answer 3

It depends on what bounded context strategy you use.

If you choose shared kernal, I think it's fine to have a direct relationship between them(direct reference or identifier reference, I believe someone else will explain the pros and cons in other answers). and you've also mentioned these objects integrated by database tables.

But if you choose anti-corruption-layer, you'd better seperate them(use just identifier to keep the relationship), use adapter-translator to integrate(and no database integration).

Gad

Answer 4

You must think about BCs as logical separations, they are referred to how people are grouped and existent relationships between each team. Said that, you can maybe consider to keep User and Games in a single bounded context keeping together what must be together. Please refer to this amazing video Hiden lessons from the big blue book

Rickey