2 ms·
This thread may have already gone stale, but just in case not... I've found that treating configuration settings as "first class abstractions" in the Domain Mo
by AnEngineer 11y ago
This thread may have already gone stale, but just in case not...
I've found that treating configuration settings as "first class abstractions" in the Domain Model pays off quite nicely. By this, I mean grouping related settings into an immutable class which is given the configuration settings provider in one of its constructors. If there are reasonable defaults for all settings, then having a no-args constructor may be acceptable as well.
For example, in Scala I have types such as:
<pre>
// Assume 'config' is what can read external configuration
case class NetworkSettings (config : SomeConfigReader)
{
val rootPath = "company-name.project.network";
host : String = config.stringEntryOrDefault (s"${rootPath}.host", "localhost");
port : Int = config.intEntryOrDefault (s"{rootPath}.port", 1234);
// etc.
}
</pre>
Of course, this pattern could be used before or instead of having the ability to externalize configuration parameters.