Domain driven design 域驱动设计-ValueObjects中的继承 用户{ 名称：字符串； paymentType：paymentType； } 付款类型{ //共同属性 } 上述PaymentType（ValueObject）是否可以由这些ValueObject（子类）-信用卡、现金、支票继承 有一个域不变量表示，用户一次可以有一个PaymentType。这应该进入用户（AggregateRoot）还是PaymentType（ValueObject）

上述PaymentType（ValueObject）是否可以由这些ValueObject（子类）-信用卡、现金、支票继承

也许吧。继承在很大程度上是一个实现细节

但我不清楚这是你真正要问的问题。您的示例看起来有点像试图设计一个“联合类型”，也就是说，您可以使用一个句柄来匹配不同的模式

Scott Wlaschin的领域建模中有一个功能性幻灯片组的示例。他的博客系列文章用其他例子更详细地描述了这项技术

有一个域不变量表示，用户一次可以有一个PaymentType。这应该进入用户（AggregateRoot）还是PaymentType（ValueObject）

视情况而定。用于决定允许哪些状态转换的代码通常进入拥有状态的对象（在本例中为用户）。我们如何表示状态、实际的数据结构等等，通常存在于值对象中

---

第5章（实体、价值对象）和第6章（聚合、存储库）中描述的建模模式只是模式。对于最完美地应用这些模式，没有奖励。实现域模型的主要目标仍然相同：生成能够顺利更改的代码设计，以满足域不断变化的需求。

这两个链接非常有用，感谢共享。您是否有其他解决方案，而不是创建联合类型？还有，你在这里指的是哪本书（第5章和第6章）？Eric Evans，《领域驱动设计》（2003）。谢谢@VoiceOfUnreason。除了创建联合类型，您还有其他解决方案吗？

User <AggregateRoot>{
  name: String;
  paymentType: PaymentType;
}

PaymentType <ValueObject> {
  //Common attributes
}