When designing a domain, either way of following approaches can be used to access list of child entities inside a parent entity.1. Get/Set Following approach is straight forward and simple to implement, but anyone can overwrite the Orders collection.public User {    public IList<Order> Orders { get; set; }}or2. Controlled AccessFollowing is bit complicated, however it provides it's orders list controlled access. public User {    private IList<Order> _orders;    public User()    {        _orders = new List<Order>();    }    public IList<Order> Orders    {        get        {            return new new ReadOnlyCollection<Order>(_orders);        }    }    public void Add(Order order)    {          order.User = this;        _orders.Add(order);    }    public void Remove(Order order)    {        if (_orders.Contains(order)        {             order.User = null;            _orders.Remove(order);        }    }}The second approach clearly has it's benefits, but it also increase the number of lines in the code (imagine when few of the collections are in the entity). So the question is, is it worth the trouble?
Controlled access to list of entities vs get/set access in domain model
domain driven design;entity
Important question: in the first example, where does the code that enforces the business invariant live?The first approach looks simple and straight forward because all the hard stuff has been moved somewhere else!So, in order:public User {    public IList<Order> Orders { get; set; }}This is bad, because the constraint on the list of users has been moved outside the entity.user.getOrders().add(invariantViolatingOrder);Your second approach is better, but still has problemspublic User {    public IList<Order> Orders    {        get        {            return new new ReadOnlyCollection<Order>(_orders);        }    }}This protects the collection against change, but it doesn't protect the Order's from being changed in a way that violates the invariant.user.getOrders().getOrder(2).invariantViolatingChange();The order entity can enforce an invariant of its own state, but it can't enforce an invariant of the combined state.  (Contrived example: this particular user is only allowed $20 dollars of orders.  You have to check the entire collection to verify that it's ok to change this one order).The easiest way to ensure that an invariant is enforced at every point that changes the state of an entity, is to make sure there is only one place where the state can be changed, and enforce it there.  In OO terms, this is encapsulation.public User {    public IList<Order> Orders    {        get        {            // By returning a copy of the state, we ensure that nothing            // outside the user can change its state.            IList<Order> readOnly = new List<Order>();            for (Order o : _orders) {                // Turtles all the way down: this depends on the order                // providing copies of its own state.                readOnly.add(o.clone());            }            return readOnly ;        }    }}Another possibility is to treat the internal state of an entity as an immutable value type.  Getting immutable state is perfectly fine, because there's no way that the immutable state can be used to violate the business invariant.But again, this second solution is turtles all the way down; you have to be careful about including entities in a value object.