【问题标题】:Domain Driven Design - Entities VO's and Class Hierarchy领域驱动设计 - 实体 VO 和类层次结构
【发布时间】:2010-01-03 22:08:57
【问题描述】:

问题的简短版本:“是否可以有一个超类,有 2 个子类,一个是实体,另一个是值对象?”

到更长的版本: T 有一个 Team 超类。 团队MasterHelpersCode。 然后我有 DefaultTeamTeam 的子类,它是一个具有 唯一 **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,是执行Task的团队。 当需要执行一个Task时,我们选择一个DefaultTeam来执行它。 但是我们可以改变 DefaultTeam 中的 Helpers(主人永远不会改变)。

执行任务的团队是 DefaultTeam (OriginalTeam) 的变体,但其中的 Helpers 仅用于那个任务。

ExecutionTeam 将具有与 OriginalTeam 相同的代码。所以ExecutionTeam 没有唯一的身份。 如果同一 DefaultTeam 执行 10 次任务,则将有 10 个 ExecutionTeams 具有相同的代码(具有相同的 OriginalTeam)。所以 ExecutionTeam 不能是实体。

但是让一个实体和一个值对象共享同一个超类(都是团队)有点奇怪。也许这个领域模型有问题。

需要意见。

谢谢

【问题讨论】:

    标签: domain-driven-design class-hierarchy


    【解决方案1】:

    是什么让 DefaultTeam 成为值对象而不是实体? DefaultTeam 不也是一个实体吗?

    话虽如此,这里有一些 cmets:

    1. 为什么需要 DefaultTeam 的特殊类? DefaultTeam 不能简单地成为具有某些指定值的 ExecutionTeam 吗?

    2. DefaultTeam 可能应该是与应用程序域关联的 Team 的一个实例。例如,您可能有一个通常用于解决 Project XYZ 问题的特定团队。

    3. 与其将“DefaultTeam”列为 ExecutionTeam 的属性,不如将“PreviousTeam”列为 Team 和 ExecutionTeam 类的属性。 这将更普遍,以防团队再次发生变化。

    4. 由于Task是域的重要组成部分,并且分配给了一个Team,它应该是Team的一个属性。

    5. “帮助者”似乎不适合团队成员。为什么不直接将他们命名为“成员”或“团队成员”?

    6. “Master”可能不是 PC,除非您在 Dilbert 地区工作或处理数据库 :) 您可能希望将其更改为“Supervisor”或“Manager”。

    7. “代码”在您的应用程序上下文中可能是一个不好的名称,因为它很容易与编程代码混淆。您可能想改用“Id”或“TeamId”。

    【讨论】:

    • 嗨,名字是从葡萄牙语到英语的粗略翻译,原来的名字更正确:)。
    • “为什么你需要一个 DefaultTeam 的特殊类?DefaultTeam 不能简单地成为一个具有某些指定值的 ExecutionTeam 吗?”如果我在特定日期 d1 与团队 t1 执行任务 t1,那么当我在另一个日期 d2 执行另一个任务 t2 并且我想使用团队 t1,但与不同的成员,如果我没有执行团队概念,那么当我更改 t1 成员时,该更改将反映在较旧的任务 t1 执行中,如果我想为他们执行的任务支付团队 t1 的工作人员,那么最后定义的 t1 的成员将获得所有的钱。
    • 因此,执行团队就像默认团队的快照,其中包含选定的成员,当他们执行任务时。
    • 啊,好吧 :) 我不知道这个程序是用葡萄牙语写的。
    【解决方案2】:

    听起来像 ExecutionTeam 可能更好地建模为接口ICanExecuteTasks。这对你有用吗?它将消除您正在努力解决的问题..

    至于您的简短问题,如果ExecutionTeam 确实是Team 的派生类,(从团队继承并代表“IsA”关系,那么答案是否定的,它们不能属于不同类型,因为当然,每个ExecutionTeam都是一个Team,只有一个东西,既是Team又是ExecutionTeam……不能同时是实体类型和值类型。

    但是你设计类的方式,因为你有结构化的东西,ExcecutionTeam 不是派生类,它是DefaultTeam 的属性。这意味着它们具有“HasA”关系。这意味着它们是不同的共存对象,其中一个可以是实体,而另一个可以是值类型。但我的直觉告诉我,这不是你真实领域模型的准确镜像......

    【讨论】:

    • 是的,我认为我们将不得不审查域模型。 DedaultTeam,没用,如果团队助手是可变的,他们在那里没有意义,团队主管是默认团队中唯一的相关信息......默认成员的唯一目的是我们的客户将与其他成员相比,他们更常与该团队主管一起使用
    • 嗯嗯嗯,持续的领域模型审查和修改,在每一步都对领域有更深入的了解,并在你的技术设计中做出相应的改变,使其也进化到更接近更深层次的理解,实际上是 DDD 的标志,也是您正确执行 DDD 的好兆头! ——
    猜你喜欢
    • 1970-01-01
    • 2011-01-05
    • 2010-10-05
    • 1970-01-01
    • 2020-10-26
    • 1970-01-01
    • 1970-01-01
    • 2011-08-01
    相关资源
    最近更新 更多