C# 我是否将值对象看得太远（DDD）

编辑： 为清楚起见，这个问题与DDD有关，DDD有一个称为值对象的概念，这些不是值类型，它们是一种构建对象的方式，内容构成了标识，我试图理解这些概念应该应用到什么程度（从评论来看，它们似乎不应该渗透到域之外）。对于不熟悉DDD的人来说，这个问题可能看起来很奇怪，但要清楚，它是关于创建对象而不是创建值类型的非常具体的机制

考虑以下示例代码，它有两个值对象：

public class SqlServerConnectionSettings
{
    public string DatabaseName { get; set; }

    public string ServerName { get; set; }

    public SqlServerCredentials Credentials { get; private set; }

    public SqlServerConnectionSettings(SqlServerCredentials credentials)
    {
        Credentials = credentials;
    }

    public string AsConnectionString()
    {
        //Snip
    }
}

public class SqlServerCredentials
{
    public string Username { get; private set; }

    public string Password { get; private set; }

    public bool UseIntegratedSecurity { get; private set; }

    public SqlServerCredentials(string username = "", string password = "", bool useIntegratedSecurity = true)
    {
        Username = username;
        Password = password;
        UseIntegratedSecurity = useIntegratedSecurity;
    }

    public string AsConnectionStringCredentials()
    {
       //Snip
    }
}

---

我没有为用户名、密码、UseIntegratedSecurity创建不同的参数，而是创建了一个值对象来保存它们。我的问题是，这是不是让概念走得太远了，我是否误解了点值对象的设计目的？

看起来不错。如果将属于同一个单位的项目分组，会有什么错误？

这取决于您的上下文

• 如果将

  SqlServerCredentials

  定义为一个实体，是的，您做得太过分了：

实体是不由其属性定义的对象，而是由连续性线程及其标识定义的对象

• 如果您将

  SqlServerCredentials

  定义为值对象，那么您是对的（不要忘记它应该是不可变的！）：

“值对象是包含属性但没有概念标识的对象。它们应视为不可变。”

• 如果将

  SqlServerCredentials

  定义为聚合，那么您也是对的：

n聚合是由根实体（也称为聚合根）绑定在一起的对象的集合。聚合根通过禁止外部对象持有对其成员的引用来保证聚合内所做更改的一致性

---

总之，以DDD的方式，如果您不考虑将

SqlServerCredentials

作为一个实体，那么这是可以的。但这一切都与上下文有关。

看起来是个不错的方法。凭据与连接设置是一个独立的实体，因此可以创建到它们自己的类中。这允许您将来向

SqlServerCredentials

添加更多选项，而无需公开类的基本机制。您的问题相当主观。但如果你觉得它是对的，那么它可能是对的。请更正单词的拼写。@KlausByskovHoffmann这不是哪一个“似乎”正确的问题。有很多人在做DDD，我想知道什么时候一个价值目标是必要的，什么时候是多余的。修复了拼写错误。我宁愿称之为基础架构，而不是域的一部分。@jgauffin我同意，我不会在特定于域的基础架构中放太多东西，但我确实发现基础架构中有“迷你域”。我想，我关心的是维护。但另一方面，我认为对SqlServerCredentials或其属性的任何验证都会很好地打包到自己的VO中。清晰、有目的的代码比紧凑性更有助于维护。因此，在我看来，您的方法是非常可维护的。