[illuminant]

It sounds like a lack of coherent design strategy. That is the sacrifice feature driven projects face. A problem which usually wears in after about three years. After market entry yet right when regular additions pile up and begin to cross paths.

The solution is a maverick mind who can drive coherent code strategy.

Business logic isn't your problem, an unfaithfulness to the idea that the application is first a business logic machine may be. User interface should be a layer, instantiating and manipulating a logic API.

Configuration over code is one ideal philosophy. Design such that configuration may established what types of things, or where they might route.

This would only work if all parts of the application agree on a configuration convention.

[headwind]

Where have you seen configurations housed? Are there any great solutions for where to store configs so that business teams also have visibility?

[illuminant]

The way I like to do it:

- use a config library (or write your own) it should read the settings.config from the root home folder.

- This library should also read settings.local.config (or equivalent.) make a git IGNORE rule for the settings.local.config so you would put credentials here and they won't be checked in to the repo.

- This local config should be read and merged into the base config by your config library (deep merge).

- Further, I like to pull additional config from the DB (for user level settings.) the fs is necessary for bootstrapping into the DB, which then may load additional preferences.

- This config format should be whatever you're comfortable with, JSON , YAML, TOML, .py/js, etc. your stack will have its own selection (and behavior) for config libraries.

And now, make sure that config is loaded and made available at the earliest point in code, and everyone can use it EASILY.

You could have this stashed into a user or system cache which your tools can then spy on to see what settings are available whichever place in code.

Settings, access control, preferences, etc. can all fit this format.

By using the git excluded '.local.' layer you can ensure API keys are never checked into git.

[illuminant]

* root home folder; that's the application home, one level ABOVE whatever passes for web root. This file should not be accessible to anyone outside of the application.

[halfcat]

We’ve done this using Django’s admin portal to let non-technical stakeholders work with database records, and it works well enough. It creates a self-serve scenario for some users, for some kinds of tasks.

The challenge is (as always) finding the right level of abstraction. A premature, wrong abstraction is way worse than making it work by hard coding some logic in the code, or (gasp) just copying and pasting the code a few times, until it’s clear which direction the abstraction is pointing, and at which level it’s operating at.

Like if you start building some generic workflow engine that doesn’t match your actual needs, you’re going to build something that’s clunky to work with, and that it’s hard to backtrack from the design decisions made. It’s better to hard code or duplicate something and remain noncommittal about architecture and design choices until you have clarity.

In practice it’s always a dance. You have to push the boundary to some degree or you’ll never build anything tangible. The usual advice of “just ship something” is not bad here, as shipping a complete failure will be a more information-rich data stream about the right direction than more planning.