3

I do not have the Eric Evans' Domain-driven design book on me, but it says essentially

External objects may not hold a reference to an entity that is internal to the aggregate. External objects must reference the aggregate root only, no internal objects.

For example, my Team aggregate root has a method called AddPlayer() and returns the Player entity added. Does this mean I am violating the rule or is it saying I cannot pull a Player entity out of thin air, for example pulling it from a repository outside of its aggregate boundary?

Russ Cam
  • 124,184
  • 33
  • 204
  • 266
Marco
  • 2,453
  • 3
  • 25
  • 35

2 Answers2

4

This is always a tricky issue and is most likely an indication that your design does not quite fit your domain. I have a bit to say about this on my blog (should you be interested):

http://www.ebenroux.co.za/post/2010/08/20/Natrual-Aggregates-vs-Synthetic-Aggregates.aspx

You have a Team and you have a Player. That would be 2 Aggregate Roots. Making Team the Aggregate Root and Player just a contained entity is what is probably causing you pain. In real life a player need not belong to a team and it also depends on what your 'team' is. Is it just the collective name, or the current members, or the actual folks that can take to the field on a given day?

So you will probably end up with different 'teams':

  • Team
  • Squad
  • GameSquad

So the players are not necessarily part of the aggregate but rather the aggregate can have some kind of ownership with probably a rather weak reference to the player (such as only an ID or some value object). Something to that effect.

But to get back to what Eric refers to in his book: I think it relates to something like this (using your mould):

var line = Order.AddLine(SomeProduct);

Here it shouldn't make too much sense having a reference to the actual entity within the aggregate as it has no lifecycle of it's own. Well, in this case the order line is not even an entity.

There has also been some discussion around whether repository only return ARs or Entities (that, in some repositories, are ARs). According to what I have found the blue book your can retrieve an entity from a repository.

Anyway. Just some thoughts. HTH :)

Eben Roux
  • 12,983
  • 2
  • 27
  • 48
  • Actually, it is for a golf outing, so my real entites are a Foursome and Player and Player does not exist without its parent Foursome. Does that help? – Marco Aug 26 '11 at 12:59
  • So lets say i need to do something with each player from my application layer, what does the order return me for the collection of players? – Marco Aug 26 '11 at 13:03
  • The `Order` was an example from an Order Processing Bounded Context. As for golfing: I would still have a Player. That player could be involved in many `Tournaments` and in many `Foursomes`. So you could, for instance, have a `Player` in a Player Management BC and a `Player` in the Tournament BC where you could add the player to the foursome. Or you could have an `AssignedPlayer` for the `Foursome`. But it all depends on your domain. – Eben Roux Aug 26 '11 at 17:46
0

I think you are reading too much into Eric Evan's guidance. I don't believe he is saying that you can't expose Player from Team. Instead, I read the rule like Eben. If Player has NO meaning outside the context of Team, then you wouldn't want to be passing around a Player, especially if the "External Object" had no concept or relation to Team. It has been a LONG time since I looked at that book. Are you sure this doesn't apply to system integration boundaries? I can't imagine Eric is saying you can't pass a player around inside your system.

Bahri Gungor
  • 2,289
  • 15
  • 16