Immutability in aggregate child entities - nested

Question

I have begun using domain driven design principles but are currently stuck with a specific problem.
I have an Aggregate which has multiple layers of nested child entities as shown below:
public class Aggregate: Entity<AggregateId>, IAggregateRoot {
private readonly List<ChildOne> childOnes;
}
public class ChildOne: Entity<ChildOneId> {
public string ChildOneValue1;
public string ChildOneValue2;
public string ChildOneValue3;
private readonly List<ChildTwo> childTwos;
}
public class ChildTwo: Entity<ChildTwoId> {
public string ChildTwoValue1;
public string ChildTwoValue2;
public string ChildTwoValue3;
}
In a domain service I need to access all values of ChildOne and ChildTwo including their ids.
public interface IDomainService {
public IEnumerable<INotification> Analyze(Aggregate aggregate);
}
However, I cannot return the entities as they are since this would violate the immutability principle.
This got me thinking that my domain model probably might not be optimal, but I cannot see how this can be different since the nested entities never can exist without the respective parent.
Another approach could be to have a single value object which holds all values of a given entity and then return this value object instead of the entity. But then a deep mapping needs to be performed since the domain service needs access to the values of all nested entities.
Any suggestions on to how to approach this?

Answer 1

Any suggestions on to how to approach this?
There are a couple of possibilities.
One is to invert your proposed API - design the domain service to accept immutable values as arguments, and then pass the instance of that service to the Aggregate, rather than the other way around.
public interface IDomainService {
public IEnumerable<INotification> Analyze(IEnumerable<DomainValue> values);
}
If you recall the Visitor pattern from the Gang of Four book, it is a very similar idea.
In some cases, an in-memory state machine might be a reasonable alternative to a stateless domain service. In that case, the API might look like
public interface IDomainService {
public void OnAnalyze(DomainValue value);
public IEnumerable<INotification> Notifications();
}
Another possibility is to design the Aggregate to act as a Collection
public class Aggregate {
// ...
public IEnumerable<DomainValue> YourCleverNameHere();
}
For use cases where you are not changing the state of the Aggregate, just leave the aggregate out of it, and work directly with an immutable in memory representation of the current state.

Answer 2

However, I cannot return the entities as they are since this would violate the immutability principle.
The entites don't need to be immutable. It's only value object that are immutable in tactical design of domain driven design.
As far as entities are aggregates are concerned, you should be able to get/save an aggregate from the repository only using the aggregate root. You should not be able to get/save an entity that is not an aggregate root.