DDD。用户可配置的设置属于哪里？
我正在开发我的第一个“真正的”DDD 应用程序。
目前，我的客户端无权访问我的域层，并通过发出命令请求对域进行更改。
然后，我有一个单独的（扁平化）读取模型来显示信息（如简单的 CQRS）。
我现在正在处理配置，或者特别是用户配置的设置。以博客应用程序为例，设置可能是博客标题或徽标。
我开发了一个通用配置生成器，它基于简单的键值对集合构建强类型配置对象（例如 BlogSettings）。我不知道这些配置对象是否是我的域的一部分。我需要从客户端和服务器访问它们。
我正在考虑创建一个包含这些配置对象的“共享”库。这是正确的方法吗？
最后，保存此类配置设置的代码应该在哪里？一个简单的解决方案是将此代码放入我的 Domain.Persistence 项目中，但是，如果它们不是域的一部分，它们真的应该在那里吗？
谢谢，
本
I'm working on my first "real" DDD application.
Currently my client does not have access to my domain layer and requests changes to the domain by issuing commands.
I then have a separate (flattened) read model for displaying information (like simple CQRS).
I'm now working on configuration, or specifically, settings that the user configures. Using a blog application as an example, the settings might be the blog title or logo.
I've developed a generic configuration builder that builds a strongly typed configuration object (e.g. BlogSettings) based on a simple key value pair collection. I'm stuck on whether these configuration objects are part of my domain. I need access to them from the client and server.
I'm considering creating a "Shared" library that contains these configuration objects. Is this the correct approach?
Finally where should the code to save such configuration settings live? An easy solution would be to put this code in my Domain.Persistence project, but then, if they are not part of the domain, should they really be there?
Thanks,
Ben
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果用户可配置的设置是基于通用语言（即“BlogSettings”）强类型化和建模的，则它们属于域。设置和其他域对象之间的唯一区别是，从概念上讲，设置是“域单例”。它们没有像其他实体那样的生命周期，并且您只能有一个实例。
通用配置生成器属于持久性，就像负责保存和读取设置的代码一样。
User configurable settings belong to domain if they are strongly typed and modeled based on ubiquitous language, i.e. 'BlogSettings'. The only difference between settings and other domain objects is that conceptually settings are 'domain singletons'. They don't have a life cycle like other Entities and you can only have one instance.
Generic configuration builder belongs to Persistence just like the code that is responsible for saving and reading settings.
发现这个问题后，我觉得有必要提出一个答案，因为我不喜欢已接受的答案。
首先，我不明白为什么这必须是单例。
其次，有关设置的一些事情非常重要：它们通常是分层的，并且几乎总是必须具有默认值的概念。有时这些默认值是在项目级别。其他时候，您可能更愿意复制一整套默认值。另外，请考虑设置可以使用继承概念的事实：也许代理有一个设置，但它允许代理执行自己的操作。
Having found this question, I feel obliged to suggest an answer because I don't like the accepted one.
First off I don't see why this has to be a singleton.
Secondly, there is something about settings that is very important: they are usually hierarchical, and they almost always have to have the concept of defaults. Sometimes those defaults are at the item level. Other times you might prefer to replicate a whole set of defaults. Also, consider the fact that settings can use the concept of inheritance: maybe an agency has a setting, but it permits agents the ability to do their own.