domain-driven-design - 让不同聚合中的实体继承自一个公共(public)类是否可以？

Question

我在属于不同聚合的几个实体中有一些共同的行为，我想将其考虑到一个抽象类中。

让不同聚合中的实体继承公共(public)抽象类有什么缺点吗？

---

用例

一些实体具有可以翻译成不同语言的名称、描述或其他属性。

例如，我会使用 setName(language, name) 设置名称并使用 getName(language) 检索它。

每种语言的每个文本都存储在一个对象中，例如:

class EntityName
{
    protected Entity entity;
    protected Language language;
    protected String text;
    protected int version;

    public EntityName(Entity entity, Language language)
    {
        this.entity = entity;
        this.language = language;
        this.version = 1;
    }

    // setText(), getText(), ...
}

对于给定的 Entity 类，EntityName 在 Entity 集合中。只有 Entity 可以通过 setName() 和 getName() 创建、读取和写入 EntityName。

但是，EntityName、EntityDescription、OtherEntityName 等类都共享几乎相同的代码。唯一没有变化的部分是对聚合的引用，因此也是对构造函数的引用。

Answer 1

关于这个主题的内容不多。但是，看看这篇标题为 How To: Domain Driven Design 的文章

请特别阅读标题为第 2 步 – 识别聚合和聚合根的部分:

In advanced situations, the presence of polymorphism in the class model can affect the aggregate boundaries as well. This occurs when multiple aggregate root classes all share the same base class

如果您存储的簿记数据(id、版本、创建时间戳、更新时间戳)在正确的域模型之外(例如，以支持您的持久层)，我认为这不是问题。但是，如果您尝试重用真正的业务方法和属性，您可以考虑用组合或 AOP 引入代替继承。

更新

查看更新后的用例后，您似乎真的在尝试实现代码重用，而不是真正的 Liskov is-a关系。一些语言通过 mixins 等概念更好地支持这种类型的重用。 (常规)或 traits (斯卡拉)。假设使用 Java，您可以做的一种方法是创建一个类并使用 Project Lombok 的 @Delegate注释以转发给您的实现。这有以下好处:

• 提供同级别的聚合封装
• 为您生成字节码，没有源代码中的所有重复
• 允许您将您的一个继承选项保存为一个真正的 is-a future 的关系
• 确保整个域的一致性

我相信这会更纯粹，并使您的模型具有灵 active 。我在一些项目中使用了 Project Lombok，并取得了巨大的成功。它允许您避开 Java 中缺少的一些语言功能，并更多地关注您的领域，而不是实现某些习语所需的必要样板代码。