Aggregate root and instances creation of child entities

Question

I have an aggregate that includes the entities A, AbstractElement, X, Y and Z. The root entity is A that also has a list of AbstractElement. Entities X,Y and Z inherit from AbstractElement. I need the possibility to add instances of X, Y and Z to an instance of A. One approach is to use one method for each type, i.e. addX, addY and addZ. These methods would take as arguments the values required to create instances of X, Y and Z. But, each time I add a new type that inherits from AbstractElement, I need to modify the entity A, so I think it's not the best solution.

Another approach is to use an abstract add method addAbstractElement for adding AbstractElement instances. But, in this case, the method would take as argument an instance of AbstractElement. Because this method would be called by entities located outside of the aggregate, following DDD rules/recommandations, are these external entities authorized to create instances of AbstractElement? I read in the Eric Evans book that external entities are not authorized to hold references of entities of an aggregate other than the root?

What is the best practice for this kind of problem?

Thanks

Answer 1

From Evan's book, page 139:

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

Meaning, you should create a factory method on the root (A) which will get the AbstractElement's details. This method will create the AbstractElement (X/Y/Z) according to some decision parameter and will add it to its internal collection of AbstractElements. In the end this method return the id of the new element.

Best Regards,

Itzik Saban

Answer 2

A few comments. As the previous answerer said, it's a good practice to use a factory method. If you can avoid it, never create objects out of the blue. Usually, it's a pretty big smell and a missed chance to make more sense out of your domain.

I wrote a small example to illustrate this. Video is in this case the aggregate root. Inside the boundaries of the aggregate are the video object and its associated comments. Comments can be anonymous or can have been written by a known user (to simplify the example, I represented the user by a username but obviously, in a real application, you would have something like a UserId).

Here is the code:

public class Video {
    private List<Comment> comments;

    void addComment(final Comment.Builder builder) {
        this.comments.add(builder.forVideo(this).build());
        // ...
    }
}


abstract public class Comment {
    private String username;
    private Video video;

    public static public class Builder {
        public Builder anonymous() {
             this.username = null;
             return this;
        }

        public Builder fromUser(final String username) {
             this.username = username;
             return this;
        }

        public Builder withMessage(final String message) {
             this.message = message;
             return this;
        }

        public Builder forVideo(final Video video) {
            this.video = video;
            return this;
        }

        public Comment build() {
             if (username == null) {
                 return new AnonymousComment(message);
             } else {
                 return new UserComment(username, message);
             }
        }
    }
}

public class AnonymousComment extends Comment {
    // ...
}

static public class UserComment extends Comment {
    // ...      
}

One thing to ponder on also is that aggregate boundaries contain objects and not classes. As such, it's highly possible that certain classes (mostly value objects but it can be the case of entities also) be represented in many aggregates.