Reputation: 5067
How do I give access to user configured settings in DDD?
We have a configuration database which stores items as a bunch of key-value pairs. This doesn't really seem to fit the repository pattern, so how do I enable the user to access these configuration values?
Ideally I'd like to have separate classes for different groupings of configuration, ie.. BillingSettings, ReportSettings, TaxSettings.
It would seem odd to provide a separate repository for each of these, but I also want to maintain persistence ignorance for these settings classes.
What is the correct way of enabling access to configuration in DDD?
Upvotes: 10
Views: 5358
Reputation: 7283
Is BillingSettings really an aggregate (or even a domain object) in your domain models? If not, it should not have a corresponding repository.
Most of the configrations are infrastructure-specific such as jdbc url, password and so on. You don't have to deal with them in the way of DDD. We may need a ConfigurationService support CRUD operations if the settings are stored in database and are allowed to be modified by users at runtime. But the ConfigurationService does not belong to the domain and this ordering bounded context, it's just an infrastructure service. We don't have to develop it in DDD way.
Update for @Kristof Jozsa's comment.
The settings are used to support an domain concept. The domain concept is abstract, and how to access settings is an implementation details.
class ExpirationSpecification {
private int days
//other settings?
public ExpirationSpecification(int days) {...}
public boolean isSatisfied(Order order) {...}
}
public class ExpirationServiceImpl implements ExpirationService {
//private int days;//inject using placeholder in spring
private ConfigurationService configService;//if settings are stored in database
ExpirationSpecification spec() {
//return new ExpirationSpecification(days);
return new ExpirationSpecification(configService.orderExpirationDays());
}
void cancel(Order order) {...}
}
Upvotes: 0
Reputation: 13256
What I typically do is just abstract the configuration using interfaces, e.g. IBillingConfiguration
, IReportConfiguration
, etc. The implementations of these are then what get passed into the relevant methods (or injected into the relevant objects).
Where the values comes from then really shouldn't matter. There are times when I do use a repository when storing the values in a database and then I'd have something like IConfigurationPropertyRepository
. It is somewhat of an awkward fit since a ConfiruationProperty
does not quite feel like a first-class citizen in the Entity world but it does seem to get the job done.
I would return some implementation of a IBillingConfiguration
that just gets the required property from an underlying collection or ConfigurationProperty
objects.
The relevant Get
and Save
methods for each I{Some}Configuration
would be implemented on the ConfigurationPropertyRepository
so that I only get/save that subset of the properties that need to be applied.
Upvotes: 3