DDD. Where do user configurable settings belong?

Question

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

Cramped

Another way of looking at it could be that you have a separate "Configuration" or "Settings" bounded context. It's a logical separation, not a physical one. Thus you can still pursue providing access to the context using various tech (client vs server). All the code to do so however, belongs to the context. – Soybean

@YvesReynhout this is the route we ended up going, having a configuration context that we interact with. We did however make the configuration objects shared - in this case, separation would have simply caused unnecessary duplication of code. – Cramped

Oh, but logical separation does not lead to code duplication. It just means the bounded context is responsible for the code. How code of the bounded context gets deployed is completely orthogonal to that fact (it could be perfectly hosted inside a process alongside code of other bounded contexts). – Soybean

Yes but we often translate logical separation into code separation. For example, my client doesn't reference my "Domain" assembly. Sometimes we have very similar objects (in this case configuration objects) on both client and in our domain. For this purpose we created a shared assembly with these objects. – Cramped

Answer 1

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.

Oleum

is it acceptable to expose these "domain singletons" to the client or should I create a "read" version for the client (that will essentially be exactly the same). I've been trying to avoid referencing my domain from the client so far. – Cramped

Treat this 'setting' object the same way you treat other entities. If you have 'read' version of other entities than it might make sense to have 'read' version of Settings as well. – Oleum

Answer 2

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.

Subclinical