Using domain objects to tame configuration complexity
Application configuration complexity arises from the number of configuration parameters, different data sources, and runtime environments. If we do not take measures, this complexity can quickly spread like a virus all over the code base and, though hardly noticeable in a particular class or object, can have a negative cumulative effect on the project’s maintainability.
Thus, the first step toward maintainable configuration is to prevent the spread and localize the complexity in a single place. We can start with the built-in Rails configuration files.
Separating application code from configuration sources
Let’s consider an example of configuring an imaginary third-party service named Layerize.cake, which provides an API to generate a layered cake recipe based on given ingredients and specifications using some AI model under the hood. To use the API, we need to provide a model ID, an API key, and a callback...