Freigeben über

Modeling Change

  • Artikel

If you have heard anything about "Oslo" (the codename for the future application platform) you have probably heard that Oslo is about 2 things, models and services.  Today I met with a group of smart guys here in Sydney where we had a chat about Models and the pain of versioning.

Everybody agrees that the only constant is change.  We know that data will change, schema will change, workflows will change, business rules will change, service contracts and data contracts will change.  We have to manage the change.

The platform infrastructure we use has semantics it applies when dealing with change.  As I mentioned in my last post, the point where the pain hits us is when new behavior encounters old state.  For example, what does the DataContract Serializer do when it encounters state that doesn't quite match up?  There are rules that it uses to deal with this.  The rules are documented but they are implicit.  You don't see them, they are not modeled but they exist never the less.

It occurred to us that if you are creating models of entities, workflows, services etc. that the modeling tool should be able to suggest a model for change.  For example, if you add an activity to a workflow.  The modeling tool can look at the delta between the previous version and your new version and suggest a model for what it will do when it encounters state from the old version.  The model could be something like, it will load the prior state and resume execution where the workflow left off when it was persisted.

Suppose you decided that this wasn't what you wanted.  What if the "change model" was itself a workflow that would execute when new behavior encountered old state?  If this were the case, you could modify this change model workflow to do what you wanted it to do. 

Suppose you are modifying a system that has 100,000 in-process workflows stored in the persistence database.  You might choose to do a batch migration process where you load them one by one and run the change model to move them forward to the new model.  Or you might choose to leave them as they are until in the course of normal processing they are loaded and then the change workflow model applies.

The meta-point is that change happens, we must deal with change, no single strategy can adequately deal with all the changes that will need to take place.  We can suggest a default, we can allow people to extend or replace the default but if we do, we ought to make the change a first class citizen of the model universe we are building.

Comments