How do we model Domain entity that has dependency on Config classes?

Question

So for e.x I have an entity Payment and a config Payment settings.

class Payment 
{ 
    public Payment(PaymentSetting setting, ....other fields){}
    internal Payment() /*strictly for the ORM**/ 
    //Other properties and behaviour
} 
class PaymentSettings 
{ 
    public Timespan TransactionTimeout {get; private set;} 
    //Other properties and behaviour
} 
class Order /AggregateRoot*/ 
{ 
    List<Payment> payments {get; private set;} 
    //Other properties and behaviour
}

There is no problem when I am going to create Payment object as I can inject the setting to constructor. But How do we inject config when the Order is loaded from DB?

I understand in the current example, Config is needed while creating the appointment only, and we can store the exact value as part of Payment object and revive it when needed. But what happens, if we need to know the latest config? Should add Methods to inject it from outside? Is it considered an acceptable practice wrt. DDD

Answer 1

Business rule configuration belongs in the domain itself. Something like

public class PaymentSettings
{
    private static readonly TimeSpan DefaultTransactionTimeout = TimeSpan.FromHours(24);

    public TimeSpan TransactionTimeout => DefaultTransactionTimeout;
}

If you have a use case that certain rules should be editable at runtime, you should create a UI for it, at which point it makes sense to store the value in the database.

Answer 2

I mostly agree with Rik D's answer, but I would make one modification: allow the transaction timeout to be set from the public context. Then you just need a little glue code closer to the composition root of the application to read the values from the config file and set the static property.

Payment.TransactionTimeout = // read from configs

Configuration data remains constant over many separate invocations of use cases. It teeters on the line between unchanging data and application state. You have correctly identified this PaymentSettings object as a little difficult to deal with. If the data only changes when the config changes, your application will likely need to be restarted or re-initialized.

Encapsulate this in your domain as static properties on certain classes using simple built-in types or enums. You could keep the PaymentSettings as a class and set that on a public static property if this info is too complex:

Payment.Settings = new PaymentSettings (/* read from configs */);

The main goal here is to decouple domain configuration from application configuration.