CODEWITHSUNDEEP
domain-driven-designrepository-pattern
NoPyGod
NoPyGod

Reputation: 5067

DDD and configuration

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

Answers (2)

Yugang Zhou
Yugang Zhou

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

Eben Roux
Eben Roux

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

Related Questions