Approaches to Configuration

Before the project acquires more features and associated configuration values, we should agree on how we want to handle configuration.

Some general thoughts I have on this, colored by the year I spent at my previous job in the team's release manager role and dealing with these pain points:

* Chaotic configurations lacking any enforcement mechanism are stressful for the people deploying and operating the application.
* I've worked in projects with strongly typed configurations backed by FluentValidator - meaning the application won't even start up if you don't provide all mandatory configuration values - and found it to be a successful approach.
* Being able to override configuration with an environment variable is often helpful.

I was going to cite Kyle McMaster's [payroll processor](https://github.com/KyleMcMaster/payroll-processor) project as an example of this but it seems he's not using it there; he and I worked together on those projects with strongly-typed config and payroll-processor is one of my go-to GitHub links when I'm trying to remember how to build approaches we worked on, or when I need an example of them. :smile: I will have to ask him if minimal APIs/etc are pushing people away from that as a best practice, or if it's just because his application doesn't have much in the way of configuration to begin with.