Creating child instances on an aggregate root in DDD

Question

I have been reading Eric Evan's book on DDD and on page 139 he states:

"if you needed to add elements inside a preexisting AGGREGATE, you might create a FACTORY METHOD on the root of the AGGREGATE"

I would assume that could be implemented something like this where the method NewLineItem is used to create and add a new line item to the order.

class Order
{
   public IEnumerable<LineItem> LineItems { get; }

   public void NewLineItem(Product product, int quantity);
}

Another way I could think of doing this is to move the factory method into the collection itself. Something like this below. I could then add a new item by calling LineItems.New(...).

class Order
{
   public LineItems LineItems { get; }

   public class LineItems : IEnumerable<LineItem>
   {
       public void New(Product product, int quantity);
   }
}

What are the pros/cons to each approach? Are there any gotchas with moving the factory method into a collection? We are currently trying to figure out the best way to implement a large domain model. We are concerned that some of these root aggregate models will get bloated with numerous factory methods and deletion methods such as RemoveLineItem(LineItem). Our thinking is that moving these factory methods to their collections helps organize the design and keeps the root aggregate less cluttered with methods. Any advice?

Thanks

plalx plalx · Accepted Answer · 2015-11-22T15:32:44

One advantage of having the factory method on the AR directly is that it makes the AR aware of the changes and allows it to enforce it's invariants. Not only that, but because the method is aware of the internal state of the AR you may be able to reduce the number of arguments passed to the factory method (most useful when creating other related ARs).

E.g. registration = course.register(registrant) vs registration = new Registration(registrant, courseId)

Also, LineItem becomes an implementation detail so the client doesn't need to be aware of that class.

The fact that you are asking this question and are actually worried of having too many methods on your ARs is perhaps an indicator that you may be clustering together objects that do not belong together.

Do not lose sight of the AR main purpose: it's a transactionnal boundary allowing to protect invariants. If there's no invariant to protect then clustering may be unecessary or even undesirable.

I would strongly advise you to read Effective Aggregate Design by Vauhgn Vernon.

Creating child instances on an aggregate root in DDD

2 Answers