Accessing entities that's not an aggregate root

Question

I'm looking at DDD and I have some thoughts. On a shopping site I have the typical Order.

public class Order
{
    public ICollection<OrderRow> OrderRows { get; set; }
    public ICollection<Payment> Payments { get; set; }
    ...
}

Payments seem to be natural to place on the Order. When placing an order or working with the order, payments is a part of the order.

But later an administrator want to handle payments separately. E.g. in the administration interface have list of payments which needs to be handled.

How should I do this? Should Payments be removed from the order and be its own root aggregate?

Answer 1

My understanding is that aggregates can and will overlap, allowing you to define the aggregate that makes the most sense for the business context of the current operation.

So in this instance, yes, when working in terms of Order you'd expose Payments as part of the Order aggregate, but this doesn't prevent you from also having a dedicated PaymentRepository that exposes Payment as an aggregate root.

Answer 2

I think that Payment entity doesn't belong to Order aggregate. As you wrote you have functionality that works with Payments separately. It means that payments are not used in Order context only. It means that Payments doesn't belong to Order aggregate :).
However it is possible to have Payments property in Order class even if it isn't a part of Order aggregate.

Answer 3

If a Payment can't exist without an Order then Payment isn't an aggregate root.

If it's not an aggregate root then loading the appropriate Order objects from an OrderRepository and operating over the Payment entities within seem to have the most DDD integrity.