Indeed, the build tag approach here seems to be just config in code (and thus in version control), switched with compile time flags. Functionally very similar to using a flag when running to do the same thing. ENV or flags for every config option does get quite complex quickly, and you also need defaults so you end up with some config in code and some config passed in (thus keeping state outside the app). I prefer a config file myself, one file per environment, and you can keep them out of version control. Another option is a config service on the private network which apps communicate with to pull configs securely.
On the database side, I simply wouldn't use mongodb, and prefer sql migrations as they're simple and portable. I also prefer using the db for testing where required rather than faking behaviour with mocks.
Agreed interfaces really must be defined at the point of use.
Overall there is far too much abstraction here in pursuit of arbitrary structure borrowed from other people (Bob Martin,12 Factor).