【发布时间】：2011-10-11 21:40:02
【问题描述】：
我正在开发我的第一个“真正的”DDD 应用程序。
目前我的客户端无法访问我的域层并通过发出命令请求更改域。
然后我有一个单独的（扁平化的）读取模型来显示信息（如简单的 CQRS）。
我现在正在处理配置，特别是用户配置的设置。以博客应用程序为例，设置可能是博客标题或徽标。
我开发了一个通用配置构建器，它基于一个简单的键值对集合构建一个强类型配置对象（例如 BlogSettings）。我不知道这些配置对象是否属于我的域。我需要从客户端和服务器访问它们。
我正在考虑创建一个包含这些配置对象的“共享”库。这是正确的方法吗？
最后，保存此类配置设置的代码应该在哪里？一个简单的解决方案是将此代码放在我的 Domain.Persistence 项目中，但是，如果它们不是域的一部分，它们真的应该存在吗？
谢谢，
本
【问题讨论】：
-
另一种看待它的方式可能是您有一个单独的“配置”或“设置”有界上下文。这是逻辑上的分离，而不是物理上的分离。因此，您仍然可以使用各种技术（客户端与服务器）提供对上下文的访问。然而，所有这样做的代码都属于上下文。
-
@YvesReynhout 这是我们最终要走的路线，有一个我们与之交互的配置上下文。然而，我们确实共享了配置对象——在这种情况下，分离只会导致不必要的代码重复。
-
哦，但是逻辑分离不会导致代码重复。它只是意味着有界上下文负责代码。有界上下文代码的部署方式与该事实完全正交（它可以与其他有界上下文的代码一起完美地托管在进程中）。
-
是的，但我们经常将逻辑分离转换为代码分离。例如，我的客户没有引用我的“域”程序集。有时我们在客户端和域中都有非常相似的对象（在这种情况下是配置对象）。为此，我们使用这些对象创建了一个共享程序集。