domain-driven-design - 领域驱动设计 : How to deal with complex models with a lot of data fields?

Question

好吧，我正在尝试为我的应用程序应用领域驱动设计原则，并使用包含数据字段和业务逻辑的丰富领域模型。我读过很多 DDD 书籍，但似乎它们的领域模型(称为实体)非常简单。当我有一个包含 10-15 个数据字段的域模型时，这会成为一个问题，如下所示:

class Job extends DomainModel{

    protected int id;
    protected User employer;
    protected string position;
    protected string industry;
    protected string requirements;    
    protected string responsibilities;    
    protected string benefits;
    protected int vacancy;
    protected Money salary;
    protected DateTime datePosted;
    protected DateTime dateStarting;
    protected Interval duration;   
    protected String status;
    protected float rating;  

    //business logic below 
}

如您所见，这个领域模型包含大量的数据字段，它们都很重要，不能被剥离。我知道一个好的富域模型不应该包含 setter 方法，而是将其数据传递给构造函数，并使用业务逻辑改变状态。但是，对于上述领域模型，我不能将所有内容都传递给构造函数，因为它会导致构造函数方法中的参数超过 15 个。一个方法不应该包含超过 6-7 个参数，你不觉得吗？

那么如何处理具有大量数据字段的域模型呢？我应该尝试分解它吗？如果是这样，怎么做？或者，我应该只使用 Builder 类或反射在实例化时初始化其属性，这样我就不会用这么多参数污染构造函数？谁能给点建议？谢谢。

Answer 1

您错过的是值对象的概念。值对象是小的、不可变的对象，在各自的领域中具有意义。

我不知道您的域的具体情况，但查看您的 Job实体，可能有一个值对象 JobDescription看起来像这样:

class JobDescription {
    public JobDescription(string position, string requirements, string responsibilities) {
        Position = position;
        Requirements = requirements;
        Responsibilities = responsibilities;
    }

    public string Position {get;}
    public string Requirements {get;}
    public string Responsibilities {get;}
}

这是 C# 代码，但我认为无论您使用哪种语言，这个想法都应该很清楚。

基本思路是 以在相应域中有意义的方式对值进行分组 .这当然意味着值对象也可以包含其他值对象。

您还应该确保值对象是按值而不是按引用进行比较的，例如通过实现 IEquatable<T>在 C# 中。

如果您使用这种方法重构代码，您将在实体上获得更少的字段，因此使用构造函数注入(inject)(强烈推荐)再次变得可行。

关于与问题没有直接关系的示例代码的进一步说明:

领域模型是整个事物，实体是其中的一部分。所以你的基类应该叫Entity而不是 DomainModel .

你应该把你类(class)的字段设为private并提供protected需要维护封装的访问器。