Storing Business Rules

Every application has some domain logic or business rules, but how much thought goes into how it is stored? Try asking yourself the following questions to help identify possible ways to serialize the domain logic.

How often will it change? Will each deployment need to have customized rules, will they be changing at run-time?

Who will be managing the domain logic? Will it be managed by people with a particular skill set? Does the domain logic need to have its own version control and distribution channel? Will the domain logic be reviewed by independent parties?

What form will the domain logic take? Can it be defined in a formal structure? Is it data driven?

There are many ways that domain logic could be stored, the most common is not always the best. Consider the following ways to serialize and store domain logic. You might use the same language as the application logic, or You might encode it in a domain specific language.

Domain logic might be stored in flat files that are compiled or in a form more suitable for a rule engine. It could be embedded in one or more XML files, for indexing and quick access. Domain logic might also be stored in a formal structure, for user-initiated rules or dynamic version control.

Domain logic can take on many forms and how it will be stored should be consider carefully. Depending on the makeup of the team or other external influences there maybe a need to make a greater distinction between domain and application logic.