Domain Driven Design - Entities VO's and Class Hierarchy

Question

The shorter version of the Question: "Is it ok to have a superclass, with 2 subclasses, one is an entity the other is a Value Object?"

To longer version: T have a Team superclass. The Team has the Master, Helpers and a Code. Then i have the DefaultTeam, subclass of Team, which is an entity with an unique *Code* has its domain identity. Then i have the ExecutionTeam, its a subclass of Team and has an extra attribute OriginalTeam:

public abstract class Team{

    public string Code{ get; protected set; }

    public Worker Master{ get; protected set; }

    public IList<Worker > Helpers { get; protected set; }
    ...

}

public class DefaultTeam: Team
{
}

public class ExecutionTeam : Team
{

    public virtual string Code { get { return OriginalTeam.Code; } }

    public virtual DefaultTeam OriginalTeam { get; private set; }

   ...

 }

The ExecutionTeam, is the team that executes a Task. When a Task needs to be executed, we choose a DefaultTeam to execute it. But we can change the Helpers from the DefaultTeam (the master never changes).

That team that executes the task, is a variation of the DefaultTeam (OriginalTeam), but with the Helpers that were chosen just for that Task.

The ExecutionTeam will have the same code has the OriginalTeam. So the ExecutionTeam has no unique identity. If there are 10 executions of tasks by the same DefaultTeam, there will be 10 ExecutionTeams with the same code (with the same OriginalTeam). So ExecutionTeam is cannot be an Entity.

But having an Entity and a Value Object sharing the same superclass (both being Teams), is a bit strange. Maybe this domain model has something wrong.

Need opinions.

Thanks

Answer 1

Sounds like ExecutionTeam might be better modeled as an interface ICanExecuteTasks. Would that work for you? It would eliminate the issue you are struggling with..

As to your short question, if the ExecutionTeam was indeed a derived class of Team, (inheriting from team and representing an "IsA" relatoonship, then the answer is No, they cannot be of different types because of course, every ExecutionTeam isA Team, thgere is only one thing, which is both a Team and an ExecutionTeam at the same time... It cannot be both an entity Type and a value type at the same time.

But the way you have designed the classes, as you have structured things, ExcecutionTeam is not a derived class, it is a property of the DefaultTeam. This implies that they have a "HasA" relationship. THis implies that they are different, co-existing objects, one of which can be an entity and one of which can be a value type. But my gut tells me this is not an accurate mirror of your real domain model...

Answer 2

What is it that makes the DefaultTeam a Value Object rather than an Entity? Isn't a DefaultTeam also an entity?

That being said, here are some comments:

1. Why do you need a special class for DefaultTeam? Can't a DefaultTeam simply be an ExecutionTeam, with certain specified values?

2. A DefaultTeam should probably be an instance of a Team that is associated with an application domain. For example, you might have a particular team that is generally used to solve problems with Project XYZ.

3. Instead of listing "DefaultTeam" as a property of the ExecutionTeam, you should probably have a "PreviousTeam" as a property of both the Team and ExecutionTeam classes. This will be more generalizable, in case the team gets changed yet again.

4. Since Task is an important part of the domain and is assigned to a Team, it should probably be a property of Team.

5. "Helpers" doesn't seem an appropriate name for the team members. Why not just name them "Members" or "TeamMembers"?

6. "Master" is probably un-PC unless you are working in Dilbert land or dealing with a database :) You might want to change this to "Supervisor" or "Manager".

7. "Code" is probably a bad name in the context of your application, as it may easily be confused with programming code. You might want to use "Id" or "TeamId" instead.