How should aggregate expose info from child entity?

Question

[ Follow up from this question Should entity have methods and if so how to prevent them from being called outside aggregate ]

I am trying to understand in full details how aggregate root exposes data from its child entities to outer world; in particular, at least repository will need that info in order to be able to save it.

So, for the sake of the argument, lets consider these rules:

1. Person have a few channels of communication: phone, email, facebook account (might as well be a collection of each of those but for simplicity lets say its just one of each).
2. Person can choose to make any of those channels public so that other Persons can contact him or make any of those private so that he can't be pinged through that particular channel.
3. Person can choose global setting of not being contacted at all. In that case, its forbidden to switch any of the phone, email, facebook to public.

[ Note: the model i'll show now might not be the best one but lets leave remodeling aside for now and focus on exposing child entity infos ]

lets say we have aggregate root Person (c# code), only with example for Phone entity as others are the same logic:

class Person {
  ...
  private Phone Phone  { get; set;}

  public bool WantsToBeContactedAtAll { get; }

  public void ExposePhoneNumberPublic() {
    if(!this.WantsToBeContactedAtAll)
      throw new SomeError("Not allowed.");

    this.Phone.PublishPhoneNumber(true);
  }

  public void HidePhoneNumber() {
    this.Phone.PublishPhoneNumber(false)
  }

}

class Phone {
  //this is identifier
  public readonly string PhoneNumber { get; private set; }
  public string Description { get; private set; }
  public boolean ShouldBePublished { get; private set; }

  public Phone(string phoneNumber, string description, bool shouldBePublished) {
    //set values
  }

  public void PublishPhoneNumber(bool preference){
    this.ShouldBePublished = preference;
  }

So, what we want to prevent is someone doing:

Person Adam = new Person(...);
Adam.Phone.PublishPhoneNumber(true);

But now, we still need info from Adam.Phone if for nothing else, then for the repository to access it when saving aggregate:

_personRepository.Add(Adam);

Questions:

1. How to expose Person.Phone info?

2. Should we expose some copy of the Phone property as a struct (value object)?

3. Have Phone as private type within Person aggregate and expose another PhoneReadOnly type what would be just a class with properties and getters.

Another way of asking those all question is: how can at least repository read Person.Phone information that it needs in order to be able to save Person?

Please treat me as a complete idiot and explain in details.

Thanks

Answer 1

I tend to think that making your child entities (immutable) value objects simplifies this issue a lot.

A rule of thumb is that you never modify a value object, you replace it. Unlike controlling what people do with the inside of your sub-entities, assigning a value to a direct property of the AR is something you can easily restrict from the root. You can just mark the setter as private and only allow changing it by going through the adequate AR method:

class Person {
  public Phone Phone { get; private set; }

  public void ExposePhoneNumberPublic() {

    if(!this.WantsToBeContactedAtAll)
      throw new SomeError("Not allowed.");

    Phone = new Phone(Phone.Number, Phone.Description, shouldBePublished: true);
  }
}

Note that the part where you take the existing Phone and new up a slightly different one could be done more elegantly - see the "with" keyword here.

Another way of asking those all question is: how can at least repository read Person.Phone information that it needs in order to be able to save Person?

I believe that's actually a totally different question. Usually, reading is not the hardest part - if you want any client code to be able to read the Phone, there's no reason that a Repository won't. Writing can be more tricky, as a well-encapsulated aggregate root doesn't necessarily let you change it like that. With ORMs, making the setters protected will work most of the time. An alternative is to use internal with InternalsVisibleTo the concrete repository's assembly, or work with a fully mutable backing state object.

Answer 2

How shoud aggregate expose info from child entity?

In a way that doesn't allow the caller to change the state of the aggregate.

• Pass a primitive value
• Pass a reference to an immutable object
• Pass a copy of an object

Copies of information are fine, because you can't change my state by changing your copy of my data. References to immutable objects are fine, because you can't change them at all, therefore you can't change my state. But giving you a reference to my mutable state increases the odds of a programmer error.

Let's consider the repository example for a moment -- repositories, remember, are used to give the application the illusion that all of the aggregates are just members of some vast, in memory collection. To support this illusion, the repository needs two functions -- one that takes a representation from our stable data store and creates from it the domain model entities that make up the aggregate, and another that takes the aggregate and constructs from it the representation to put in the data store.

Let's pretend that we had some really naive aggregate that was just an array of integers

class Aggregate {
    int [] State;
}

And then we imagine the functions that a repository might need to load and store this aggregate

Aggregate a = Aggregate.from(state)
int [] state = a.state

Now, what happens if we try to cheat?

int [] state = a.state;
state[0] = 12345;

Did a change? Since we want the domain model to be the authority for the state of the world, the answer had better be "no". Which in turn means that the aggregate doesn't yield a reference to its own array, but instead a copy of that array.

The same principle applies if we think about an aggregate with an array of child entities.

class Aggregate {
    Child [] children;
}

So what does this aggregate yield? Not it's own array, because that would allow the client to change the aggregate by replacing a Child. But it can't just copy the array either, because we could call methods on one of the child array elements to change itself, which would indirectly change the state of the aggregate.

So we don't return an array of children, we return an array of descriptions of children. It's a sort of "deep copy". The descriptions contain copies of data, but no references -- nothing that links back to the internals of the entity itself -- and so it is safe to yield the description to a caller, who can do what they like with it (including sticking the description into a document store for later recovery).