The data in the enterprise change all the time, right? Virtually every user interface interaction, API call, or event changes some data somewhere. Code, however, is static. It never changes on its own, of course ? and when people have to change it, it?s a difficult, complex proposition, especially in a legacy environment.
Maybe we have these principles backwards. What if data were static and code were dynamic? Data sets continue to grow, of course, but what if we only added to the pile, but never changed or deleted anything? And as for the code, what if the descriptions of the logic of our applications were as dynamic as the business needs call for?
On the surface these ideas may seem ludicrous, but upon deeper inspection, maybe we?re onto something. I?ve already discussed the advantages of data immutability. But for code to be dynamic, we must take another conceptual leap: to a declarative programming model.
Declarative programming separates logic from control flow. Sure, there?s static code under the covers, but all it does is read the logic files and follow their instructions. All the business logic fits into those logic files, which are thus a form of metadata.
If we follow a fully declarative programming model then it should be possible for our ?code? (that is, our metadata descriptions of application behavior) to be as dynamic as we need them to be, if only our data don?t change. Get this model right and anyone should be able to change functionality anywhere in a distributed environment without breaking anything ? in other words, comprehensive loose coupling. We tried to get loose coupling right with Web Services but fell short. Static APIs don?t solve this problem either. The secret sauce, of course, is that static code under the covers.
