Some more Aggregate Root thinking…

If a child entity in an Aggregate Root should not be accessible outside the boundaries of a Root, why should you be able to instantiate it?

If I mark their constructor with internal, it should be only instantiated from a Root (root should know how to instantiate it), this would also allow us to play with them only within the Model project, but others should get it via Root (like Services, Client applications and others).

Example…

public class Car : EntityBase<int>, IAggregateRoot
{
    public Car()
    {}

    public Wheel RightWheel
    {
        get
        {
            return new Wheel(”Right”);
        }
    }
}

and Wheel (child entity):

public class Wheel : EntityBase<int>
{
    private string _wheelType;

    internal Wheel(string wheelType)
    {
        _wheelType = wheelType;
    }
}

Again… my insecurities and concerns come from previous reasons as with the previous post:

Pros:

• Explicitness
• Active enforcing of rules

Cons:

• Cluttering the design
• Running with scissors… we like running with scissors, although we probably won’t fall on them

What do you think?

I am having double thoughts.

I am toying with an idea.

One of the pillars of DDD is the pattern of Aggregate Roots and their boundaries. Also the fact that our Repositories should only work against Aggregate Roots and not Entities themselves.

As I like explicitly to enforce my rules I am toying with an idea of a marker interface IAggregateRoot which would not contain ANY elements, just exist.

What I could do then is put a Generics constraint on my Repository like:

IRepository<EntityT, IdentifierT> where EntityT : EntityBase<IdentifierT>, IAggregateRoot

Then all my entities which are Aggregate Roots should be *marked* as one:

Category : Entity<int>, IAggregateRoot

Now… I both like and dislike this, I can’t put my mind what is better yet

Pros:

• Allows us to actively enforce DDD rules and make the users of this framework think about what their roots are and not generalize everything
• Nice explicitness of knowing exactly which entity is a Root and which is not
• In any future gives me a leverage to find out if an Entity is a Root or not if for any reason I need to get this info

Cons:

• Design noise, in it’s sense it doesn’t bring anything concrete to the table, forcing my users to do this one extra step (mark an Entity) and also clutter the design doesn’t sound too thrilling
• What would be a default setup for an entity? Probably that it is an Aggregate root (think code generating your initial model from database or any other resource). Doesn’t this then go against it? Everything is a Root. Also knowing the users, the simplest thing will be to mark them all with IAggregateRoot
  Uhhh… Tough descision.

What do you think?