Domain driven design 实体类可以从值对象继承吗?

Domain driven design 实体类可以从值对象继承吗?,domain-driven-design,Domain Driven Design,在我的业务域中,一个实体“CompanyPrefix”似乎扩展了保存所有业务规则的VO CompanyPrefixVO。没有其他类会使用此VO。作为一种良好做法: 我应该从CompanyPrefixVO扩展CompanyPrefix吗?或 删除VO并将业务规则合并到实体CompanyPrefix中?或 CompanyPrefix应仅与CompanyPrefixVO关联?或 完全不同的东西 继承可能会导致许多问题,首先是高耦合性和强依赖性,这会阻碍域模型的发展。我会用作文代替。值对象可以是实体的一

在我的业务域中,一个实体“CompanyPrefix”似乎扩展了保存所有业务规则的VO CompanyPrefixVO。没有其他类会使用此VO。作为一种良好做法:

  • 我应该从CompanyPrefixVO扩展CompanyPrefix吗?或
  • 删除VO并将业务规则合并到实体CompanyPrefix中?或
  • CompanyPrefix应仅与CompanyPrefixVO关联?或
  • 完全不同的东西

  • 继承可能会导致许多问题,首先是高耦合性和强依赖性,这会阻碍域模型的发展。我会用作文代替。值对象可以是实体的一部分

    也就是说,我还要问几个问题:CompanyPrefix将是一个什么样的商业实体?它不仅仅是名称或标识符的一部分吗?它是否有自己的生命周期,即它是否随时间改变其属性?为什么前缀需要ID?只是为了规范化(即不属于域模型的数据库详细信息?)


    我不知道您的具体情况,但可能有一个VO代表公司前缀作为公司的一部分。

    Thankyou@Dennis Traub。CompanyPrefix有自己的生命周期。公司可以有多个由不同身份提供者提供的CompanyPrefix,这些身份提供者也可能随着时间的推移而过时。所以公司前缀显然是一个实体,尽管实体名称有点混乱。它实际上是全球唯一的公司标识符。我明白你关于继承的观点,但另一方面company.companyPrefix.CompanyPrefixVO.value在我看来有点奇怪。然后我会将两者合并到前缀中。除此之外,通过一个对象直接检索包含对象的属性被认为是不好的做法。包含对象通常会封装对内部对象的访问。谷歌“告诉不要问”或“德米特定律”获取更多信息。