FAQ 4.11 What characteristics make a framework extensible yet domain-specific?

Mechanism rich, policy free.

In this context, mechanism refers to anything (information, data, procedures, processes) that is intrinsic to the problem domain; policy refers to anything that is likely to change or to be application specific. Examples of mechanism in order processing systems might include payment methods such as purchase orders, cash, cash on delivery, and credit cards, whereas the interest rate for late payment might be an example of policy.

So the ideal extensible, domain-specific framework is rich in the mechanism of the problem domain but free from policy within the problem. This makes it a suitable basis for a wide range of applications without forcing every organization to adopt the same policies. If it isn't mechanism rich, future developers won't get as much "oomph" (a technical term) as they might otherwise. If it isn't policy free, future developers will have to work around the obsolete policy.

Deciding what is mechanism and what is policy is an art. Within an extensible framework for order processing systems, is assuming that all transactions can be processed in a single currency an example of mechanism or policy? Clearly, this is situation specific. For some organizations this assumption is perfectly reasonable and it can be built into the mechanism of the framework. For other organizations the currency might change from transaction to transaction, in which case the decision of which currency to use is a policy decision that should not be built into the mechanism of the framework.