Domain driven design DDD实体工厂责任

创建实例

我是DDD新手，不知道创建实体的工厂是否负责创建价值对象。以下是我目前所拥有的一个小例子：

class User extends Entity {
    public name: UserName;

    constructor (name: UserName) {
        this.name = name;
    }
}

class UserName extends ValueObject {
    public userName: string;
}

class UserFactory {
    public create(string name) {
        return new User(
            new UserName(name)
        );
    }
}

我认为这样，创建用户（UserEntity）的组件只需将字符串传递给工厂即可。但另一方面，该准则没有遵循单一责任原则。也许直接传递用户名值对象更好

class UserFactory {
    public create(UserName userName) {
        return new User(
            userName
        );
    }
}

验证

我还不清楚的另一个概念是验证。在创建对象（UserEntity）时讨论验证。用户工厂是否对此负责？例如：

class UserFactory {
    public create(UserName userName, UserLastName userLastName) {
        if (userName == userLastName)
            // throw validation exception

        return new User(
            userName,
            userLastName
        );
    }
}

图像我将lastName添加到UserEntity作为ValueObject。我知道比较这两个名字是愚蠢的，但只是举个例子。 那么，这样做正确吗？从用户实体中删除责任，或者下面的代码片段更好：

class User extends Entity {
    public name: UserName;
    public lastName: UserLastName;

    constructor (name: UserName, lastName: UserLastName) {
        if (name == lastName)
            // throw validation exception

        this.name = name;
        this.lastName = lastName;
    }
}

---

我最感兴趣的事情是实体的构造函数发生更改时（向构造函数添加更多必需的参数）。我正在寻找一种方法，该方法将导致尽可能少的更改-仅使用实体的构造函数的工厂模式？与简单的构造函数（如果有的话）相比，使用工厂的最大优势是什么。factory模式实际上不是DDD的一部分，但它是一种设计模式，用于构建复杂的对象或隐藏实体需要使用的某些属性（例如，在UI中，元素可能需要对进行渲染的类进行访问）。如果你去duckduckgo搜索

design factory pattern

您展示的示例并不真正需要工厂。如果工厂所做的只是将参数传递给构造函数，那么它不会添加任何内容

关于验证，其思想是，如果对象不可用，则构造函数永远不会成功返回，因此在您的示例中，如果参数不能为null，则null验证应该在对象的构造函数中

关于价值对象，再说一遍，为什么需要工厂？它带来了什么好处？老实说，我想不出有哪一种情况下有一个工厂类是有意义的。有时，为了使代码更简洁，可以使用工厂方法。例如，在Java中，Optional类只能通过调用static builder方法

Optional.of（）

来构造（顺便说一句，它执行一些仅适用于该方法的额外验证）

---

TL；DR：如果Factory类带来好处，请使用它，否则只需直接实例化类。

谢谢您的回答。就我所知，在我给出的示例中，使用工厂模式是没有用的。但是你能给我举几个例子说明什么时候使用它是好的吗。此模式缓存以前创建的对象。工厂的职责是保持缓存并返回以前创建的对象。可能还有几百个其他用例使用这种模式。