问题
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?
回答1:
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 :)
回答2:
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.
来源：https://stackoverflow.com/questions/7204573/domain-driven-design-aggregate-referencing-question