Domain driven design DDD。用户可配置设置属于哪里？

我正在开发我的第一个“真正的”DDD应用程序

当前，我的客户端无法访问我的域层，并通过发出命令请求对域进行更改

然后我有一个单独的（扁平化的）读取模型来显示信息（比如简单的CQR）

我现在正在进行配置，或者特别是用户配置的设置。以博客应用程序为例，设置可能是博客标题或徽标

我开发了一个通用配置生成器，它基于一个简单的键值对集合构建一个强类型配置对象（例如BlogSettings）。我无法确定这些配置对象是否属于我的域。我需要从客户端和服务器访问它们

我正在考虑创建一个包含这些配置对象的“共享”库。这是正确的方法吗

最后，保存这些配置设置的代码应该在哪里运行？一个简单的解决方案是将这些代码放在我的Domain.Persistence项目中，但是，如果它们不是域的一部分，它们真的应该存在吗

谢谢

---

Ben

如果用户可配置的设置是强类型的，并且基于普遍存在的语言（即“BlogSettings”）建模，则它们属于域。设置和其他域对象之间的唯一区别是，概念上的设置是“域单例”。它们不像其他实体那样有生命周期，您只能有一个实例

---

通用配置生成器属于持久性，就像负责保存和读取设置的代码一样。

可以将这些“域单例”公开给客户端，还是应该为客户端创建一个“读取”版本（本质上完全相同）。到目前为止，我一直试图避免从客户端引用我的域。请像对待其他实体一样对待此“设置”对象。如果您有其他实体的“读取”版本，那么也可以使用设置的“读取”版本。另一种查看方式可能是您有一个单独的“配置”或“设置”绑定上下文。这是逻辑上的分离，而不是物理上的分离。因此，您仍然可以使用各种技术（客户机与服务器）提供对上下文的访问。但是，所有这样做的代码都属于上下文。@YvesReynhout这是我们最终要走的路线，有一个与之交互的配置上下文。不过，我们确实共享了配置对象——在这种情况下，分离只会导致不必要的代码重复。哦，但是逻辑分离不会导致代码重复。它只是意味着有界上下文负责代码。有界上下文的代码是如何部署的，这与事实完全正交（它可以与其他有界上下文的代码一起完美地托管在一个进程中）。例如，我的客户端不引用我的“域”程序集。有时，我们在客户端和域中都有非常相似的对象（在本例中是配置对象）。为此，我们使用这些对象创建了一个共享程序集。