领域驱动设计 - 实体 VO 和类层次结构
问题的简短版本：“可以有一个超类，有两个子类，一个是实体，另一个是值对象吗？”
到更长的版本： T 有一个团队超类。 团队有主人、助手和代码。 然后我有 DefaultTeam，Team 的子类，它是一个具有唯一 **Code**** 的实体，有其域标识。 然后我有 **ExecutionTeam，它是 Team 的子类，并且有一个额外的属性 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; }
...
}
ExecutionTeam 是执行任务的团队。 当需要执行任务时，我们选择一个DefaultTeam来执行它。 但是我们可以从 DefaultTeam 中更改 Helpers （master 永远不会改变）。
执行任务的团队是DefaultTeam (OriginalTeam) 的变体，但具有专为该任务选择的Helpers。
ExecutionTeam 将具有与 OriginalTeam 相同的代码。因此执行团队没有唯一的身份。 如果同一个 DefaultTeam 执行 10 次任务，则将有 10 个具有相同代码的 ExecutionTeam（具有相同 OriginalTeam）。因此 ExecutionTeam 不能是实体。
但是让实体和值对象共享同一个超类（都是 Teams）有点奇怪。也许这个领域模型有问题。
需要意见。
谢谢
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
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
是什么让 DefaultTeam 成为一个值对象而不是一个实体？ DefaultTeam 不也是一个实体吗？
话虽如此，这里有一些评论：
为什么需要为 DefaultTeam 提供一个特殊的类？ DefaultTeam 不能只是一个带有某些指定值的 ExecutionTeam 吗？
DefaultTeam 可能应该是与应用程序域关联的团队的实例。例如，您可能有一个通常用于解决项目 XYZ 问题的特定团队。
您可能应该将“PreviousTeam”作为 Team 和 ExecutionTeam 类的属性，而不是将“DefaultTeam”列为 ExecutionTeam 的属性。
这将更加通用，以防团队再次发生更改。
“助手”对于团队成员来说似乎不太合适。为什么不直接将他们命名为“Members”或“TeamMembers”？
“Master”可能不是 PC 的，除非您在 Dilbert 领域工作或处理数据库:) 您可能想将其更改为“Supervisor”或“Manager”。
“代码”在您的应用程序上下文中可能是一个不好的名称，因为它很容易与编程代码混淆。您可能想使用“Id”或“TeamId”。
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:
Why do you need a special class for DefaultTeam? Can't a DefaultTeam simply be an ExecutionTeam, with certain specified values?
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.
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.
Since Task is an important part of the domain and is assigned to a Team, it should probably be a property of Team.
"Helpers" doesn't seem an appropriate name for the team members. Why not just name them "Members" or "TeamMembers"?
"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".
"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.
听起来 ExecutionTeam 可能更好地建模为接口
ICanExecuteTasks。这对你有用吗？它将消除您正在努力解决的问题..至于您的简短问题，如果 ExecutionTeam 确实是 Team 的派生类（继承自 team 并代表“ IsA”关系，那么答案是否定的，它们不能是不同的类型，因为当然，每个 ExecutionTeam 都是一个 Team，这只是一件事，它既是一个
Team又是一个ExecutionTeam< /code> 同时...它不能同时是实体类型和值类型，但是您设计类的方式（就像您构建事物一样），
ExcecutionTeam是。不是派生类，它是 DefaultTeam 的属性。这意味着它们具有“HasA”关系，这意味着它们是不同的共存对象，其中之一可以是实体。其中之一可以是值类型，但我的直觉告诉我这不是真实域模型的准确反映......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
ExecutionTeamwas indeed a derived class ofTeam, (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 aTeamand anExecutionTeamat 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,
ExcecutionTeamis not a derived class, it is a property of theDefaultTeam. 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...