Maintaining legacy data is hard

I smiled when I saw that even the folks at Flickr admit to having trouble maintaining their legacy data.

On my work project, the most difficult aspect to maintaining legacy data is usually caused by the evolving domain model constraints.  In particular, when you try to create explicit relationships among entities that previously were only inferred, or not previously required.  The legacy data invariably seems to violate the relationship constraints, forcing the model to allow for and handle missing relationships.

For those familiar with the Screensaver domain model, this occurred when migrating the PlatesUsed entity to AssayPlate.  PlatesUsed did not have an explicit relationship with Copy, but only maintained the Copy name, as a text value.  When the PlatesUsed entities were converted into AssayPlate entities, there were missing Copy name values.  Furhtermore, many AssayPlates were not defined at all, even though they were screened.  This forced us to create AssayPlates for which the Copy is unknown.  In both cases, the domain model had to allow for and handle AssayPlates that did not have an associated Copy.  But since every AssayPlate absolutely needed to know its library plate number, we had to store that redundantly in AssayPlate, even though it could be determined via AssayPlate.Copy.Plate.plateNumber.

Domain-Driven Design

Started reading Domain Driven Design. Will try to write about my thoughts on the book and the subject as I proceed.

The key point thus far is that the domain very much represents a common language that will be used to communicate ideas, requirements, and behaviors (both of the system and the business) between developers and domain experts. At the same time it must be comprise a functional piece of a software system. This dual role will help keep the requirements of the users and the design of the software in sync. The model should not in any way be concealed from the domain experts (and users). It should be used as the language of communication. When either side finds it difficult to communicate aspects of the software or of the business using only the lexicon of the model, it is quite likely that the model is not "right", in that it either does not properly "map" to reality, is overly complicated or focused on technical (software) details, or is incomplete.

Accept that that the model will never be perfect, but must evolve continually evolve as everyone (developers and domain experts) works towards the development of the software. It is important to remember that even the domain experts, while knowing the business side very well, may not know how to formulate their understanding into a formal (and executable) model.
The model does not need to model everything known about the business, only what is pertinent to the current goals of the software system. It is a model of some reality, after all, and not a duplication of reality.