views:

80

answers:

1

alt text Marked my aggregate roots with 1;2;3. Looks quite nice - almost like grapes.

alt text

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 company country on hiring operation sounds reasonable?

Any other ideas?

How can I get my grapes look like they should?

+3  A: 

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.

Jeff Sternal
And what exactly that changes? Give a bit more details. :)
Arnis L.
Heh, sorry to be so terse. I'm sort of prompting you for more details too. :) My position is that there's nothing wrong with your design as you've described it. What do you dislike about your current design? Why do you think that you might need to promote country to an aggregate root?
Jeff Sternal
Cause 2 aggregate roots shouldn't reference same entity. Isn't that correct? It`s different for value objects?
Arnis L.
There's no problem with 2 aggregate roots referencing the same entity - they just can't reference another aggregate's *internals*. It is different for value objects, which are simpler. Consider how you can reference dates, like "August 20th, 2010," any number of times in your classes. There are surely applications (or bounded contexts) in which countries should be full-fledged entities that encapsulate child objects and business logic, but from your description this isn't one of them.
Jeff Sternal
It kind a sounds right to me. Just need to make sure they act as value objects at persistence level too.
Arnis L.
But the real answer is: `Right click on those arrows and hit "Show as property"`. :)
Arnis L.