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