Synchronizing code ... with data models
A typical server side, enterprise application taps data from databases and other stores, transforms it, and makes it available to different access mechanisms such as web.
Typical synchronization mechanisms watch changing data at one datastore, and replicate them at another (possibly mobile, disconnected, replicated ...) datastore. 'Watching' either means polling the data to identify changes (less common), or inserting triggers into Databases, or accessing changelogs of LDAP directories.
But consider another case: How often you have to change the application code because the data model, or the schema changed? Are there regular patterns?
Some of such patterns are already observable. For example, if you choose LDAP as your datastore, you are shielding the data model from the applications to some extent. Adding a new attribute in LDAP will not require that you change your code. If you used good coding practices, the attributes could be made available to both business logic and presentation interfaces without having to change any piece of code.
However, business logic heavily depends on data models. And typically, the very purpose of adding new attribute would be to introduce new business logic. The term 'synchonization' in this context would mean that the business logic is expressed in adata transformation language model - for example XSLT. And it should be possible for us to create a synchronization model that connects Data model in backend stores, business logic in XSLT specifications, and Presentation layer components such as menus, lists etc.
One thing to note: In any synchronization, the changes happen independently at one point, and get replicated elsewhere. In this model, the changes would be driven by any layer. For example, I might use a website design tool to add a new attribute (say, "size") to an item being shopped, and expect it to appear in (say) LDAP schema automatically. Once introduced this way, this schema element might become available to other team members for use in other screens.
Does this model make sense? If it does, it would make it very easy to write applications.
