Hi anders,
The way I tend to think about this is that the business code should not be concerned with the technical details of configuration. It’s up to the IT/Ops services to decide where configuration comes from, and any policies associated with it. I would say that the configuration object belongs to the service that uses it, but that ITOps may impose some conventions on it.
For instance, I often include some code in my dependency injection container to fill properties from configuration if the class name ends in Settings. You could do something similar with a marker interface (like IMessage, IEvent, and ICommand in NServiceBus) instead. The configuration class belongs to the service. The dependency injection container extension that fills the class belongs to IT/Ops. Both get deployed in your website.
Putting the configuration in the appsettings.json file is an IT/Ops decision. How transparent is that decision to code in other services? If you decide to move the configuration to a database or to Azure App Configuration, how much of the code base do you need to update? Ideally you make the change in one spot (inside IT/Ops) and everything now has access to the new configuration option. Your business code doesn’t require a change.
The service defines what can be configured. IT/Ops defines how it can be configured.
Let me know if that helps.
-Mike