DDD 中的应用程序级别设置？

只是想了解小组对如何处理实体的配置细节的想法。

我具体想到的是可能由管理员更改的高级设置。您最终可能会存储在应用程序或 web.config 中，但从 DDD 角度来看，应该在对象中的某个位置显式设置。

为了方便讨论，我们以基于 Web 的 CMS 或博客应用程序为例。

给定的博客条目实体具有任意数量的实例设置，例如作者、内容等。

但您可能还希望设置（例如）默认说明或关键字，如果作者未更改这些内容，则站点中的所有条目都应以它们开头。当然，您可以在类中设置这些常量，但站点所有者无法更改默认值。

所以我的想法如下：

1) 使用类级（静态）属性来表示这些设置，然后在应用程序启动时设置它们，可以从数据库或 web.config 进行设置。

or

2）使用单独的实体来保存设置，可能是字典，可以直接使用它，也可以让它成为 Entry 类的成员

你们觉得什么最简单/最灵活？我对第一个的担忧是，它并不让我觉得可插拔（如果我最终想要添加更多功能），因为更改实体的类方法也会让我更改应用程序本身（这感觉像是违反 OCP 规则） ）。不过，第二个感觉更重，特别是如果我必须从字典中转换或解析值。

我想说，从领域模型的角度来看，一个值是否可配置并不重要——重要的是它是外部定义的。

假设您有一个必须有名称的类。如果始终需要名称，则无论值的来源如何，都必须将其封装为不变量。这是一个 C# 示例：

public class MyClass
{
    private string name;

    public MyClass(string name)
    {
        if(name == null)
        {
            throw new ArgumentNullException("name");
        }

        this.name = name;
    }

    public string Name
    {
        get { return this.name; }
        set
        {
            if(value == null)
            {
                throw new ArgumentNullException("name");
            }
            this.name = value;
        }
    }
}

像这样的类有效地保护了不变量：名称不能为空。领域模型必须封装这样的不变量，而不考虑哪个消费者将使用它们 - 否则，它们将无法满足柔软设计的目标。

但您询问了默认值。如果您有一个很好的 Name 默认值，那么如何将该默认值传达给 MyClass。

这就是工厂派上用场的地方。您只需将对象的构造与其实现分开即可。无论如何，这通常是一个好主意。选择抽象工厂还是构建器实现并不那么重要，但抽象工厂是一个不错的默认选择。

对于 MyClass，我们可以定义 IMyClassFactory 接口：

public interface IMyClassFactory
{
    MyClass Create();
}

现在您可以定义一个从配置文件中提取名称的实现：

public ConfigurationBasedMyClassFactory : IMyClassFactory
{
    public MyClass Create()
    {
        var name = ConfigurationManager.AppSettings["MyName"];
        return new MyClass(name);
    }
}

确保需要 MyClass 实例的代码使用 IMyClassFactory 来创建它，而不是手动新建它。