DDD modeling, interaction between aggregate roots

Thing I dislike is an entity that's marked with red arrow.

Let's imagine that:

• AR #1 is company
• AR #2 is office
• AR #3 is employee
• Entity marked with red arrow is named Country
  • Company sets the rules from which countries it hires employees (on hiring, company.Countries.Contains(employee.Country) must be true)

I somehow see this quite unimportant part of domain (maybe it does not sound like that in this example one), and I would like to avoid promoting Country to aggregate root.

Glossary about aggregate roots says:

Transient references to the internal members can be passed out for use within a single operation only.

So - does introducing something like 'EmployeeCountry', removing reference to company Country and checking if Employee country matches any开发者_JAVA百科 company country on hiring operation sounds reasonable?

Any other ideas?

How can I get my grapes look like they should?

In this context Country is just a value object, not an entity - much less an aggregate root - so there's no reason to change anything about your design (without more information).

Additionally, note that the warning you cite pertains to internal members of aggregate roots, not aggregates themselves. There's nothing wrong with maintaining references to aggregates in multiple places. Aggregate roots are supposed to encapsulate child objects so that there's a single place to enforce business rules for related objects.

You can see this clearly in several places in Evans' "Domain-Driven Design" (a.k.a., "The Blue Book"). For example, see the diagram on page 127 (in the introduction to aggregate roots), which shows a Car aggregate that has a reference to an Engine aggregate.