DDD and configuration

Question

How can I provide access to user-configured settings in DDD?

We have a configuration database that stores items as a pair of key-value pairs. This actually doesn't look like a repository template, so how do I let the user access these configuration values?

Ideally, I would like to have separate classes for different configuration groups, i.e. BillingSettings, ReportSettings, TaxSettings.

It would seem strange to provide a separate repository for each of them, but I also want to preserve ignorance of persistence for these settings classes.

What is the correct way to enable configuration access in DDD?

Answer 1

What I usually do is just an abstract configuration using interfaces, for example. IBillingConfiguration , IReportConfiguration , etc. The implementation of this data is then transferred to the appropriate methods (or entered into the appropriate objects).

In cases where the values ​​come from this, it really does not matter. There are times when I use the repository when storing values ​​in a database, and then I have something like IConfigurationPropertyRepository . This is somewhat inconvenient, as ConfiruationProperty doesn't quite feel like a first-class citizen in the Entity world, but seems to be doing its job.

I would return some implementation of IBillingConfiguration , which simply gets the required property from the base collection or ConfigurationProperty objects.

The corresponding Get and Save methods for each I{Some}Configuration will be implemented on the ConfigurationPropertyRepository , so I only get / save this subset of the properties that need to be applied.

Answer 2

Is BillingSettings an aggregate (or even a domain object) in your domain models? If not, it should not have an appropriate repository.

Most configurations are infrastructure dependent, such as jdbc url, password, etc. You do not need to deal with them in the DDD path. We may need support for ConfigurationService CRUD operations if the settings are stored in a database and allowed to be changed by users at runtime. But the ConfigurationService does not belong to the domain, and this ordered limited context is just an infrastructure service. We do not need to develop it in DDD mode.

Update for @Kristof Jozsa's comment.

Settings are used to support the concept of a domain. The concept of a domain is abstract, and how to access the settings are 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) {...} }