Declarative Application Design

Some miscellaneous thoughts on designing applications to support declarative instantiations.

I find that as an application design matures, it evolves towards a declarative design, where the procedural/imperative code implements the mechanism/machinery of the application, and the declarative "code" implements the "policy", which is to say that it defines an instance of the application for a particular customer (business rules, UI look & fool, etc.). E.g., Data table columns are declared, rather than being specified in code; user interface is declared in *.xhtml files; etc.

It seems like all frameworks evolve from particular application instances, and that as developers seek to generalize their solutions, they create this separation between the mechanism and the policy implementations. At this point a framework emerges.

The need for a clear separation between the mechanism and the policy is certainly coming to the forefront as a concern on my current project, as the application is being adopted by other customers and will need to be configurable for each customers' particular needs.

A highly declarative application design would mostly get around the web application server restart problem, since the declarative portions are not Java, but text configuration files, which can be reloaded by the application. We already see this working with UI design, which is easily modified and redeployed with .xhtml files.

With a declarative design, I begin to think of unit tests as those which test the mechanism implementations, and the acceptance tests as those that test the policy.