The problem is that it
can be hard to figure out what changes, and even if you know
what changes then it can be hard to figure out how to describe
the change in your database. Code is powerful, and it can be
hard to make your data as powerful as your code without making
it as complicated as your code. But when you are able to figure
out how to do it right, metadata can be incredibly powerful, and
can decrease your maintenance burden by an order of magnitude.
Or two.
The era when business rules were buried in code is coming to an end.
Today, users themselves often seek to dynamically change their
business rules without the writing of new code. Customers require
that systems are built that can adapt more easily to changing business
needs, that can meet their unique requirements, and can scale to large
and small installations.
Adaptive Object-Models successfully confront the need for change by
casting information like business rules as data rather than code. In
this way, it is subject to change at runtime. Using objects to model
such data and coupling an interpretation mechanism to that structure,
we obtain a domain-specific language, which allows users themselves to
change the system following the evolution of their business.
A system with an Adaptive Object-Model has an explicit object model that
it interprets at run-time. If you change the object model,
the system changes its behavior. For example, a lot of workflow
systems have an Adaptive Object-Model. Objects have states and
respond to events by changing state. The Adaptive Object-Model defines the
objects, their states, the events, and the conditions under
which an object changes state. Suitably privileged people can change
this object model "without programming". Or are they
programming after all? Business rules can be stored in an Adaptive Object-Model that makes it easy to evolve the way a company
does their business. |
