Policy Vs. Mechanism

As best you can, keep separate policy from mechanism in the software that you build. In keeping separate policy and mechanism, you build more general, reusable software than if you had coupled them together.

Defaults, hard coded values, unconfigurable behavior, and especially misplaced rules or data, are all examples of policy. When baked into the mechanism, it single purpose-ifies your invention. No bueno!

Think of the policy vs. mechanism problem as a layering problem. I.e., on the lower layers you should have flexible, reusable components, and on the upper layers you have more opinionated, pre-configured components. Operating systems are a good case study of why the separation of mechanism and policy is important.

Keeping separate mechanism from policy helps remove you and your system from expensive consensus building exercises. If your system can support whatever policy out there, consensus building on which policy to implement becomes a tomorrow problem.

\n