Why we view a domain model as a tree

In some feedback to my last posting, there was a question about why we visualized a domain model as a tree, with the point that this seemed inappropriate for some domain models. This is an interesting question, and warrants a more public response. So, here goes.

  • The visualization is a tree view of a graph of classes (actually  tree views of two graphs - the inheritance and relationship graphs). In the tool you have a good deal of control over how you want to view the graph as a tree.
  • The tree views certainly enables the expand/collapse and automated layout, both things which we wanted in the tool
  • But, perhaps most importantly, it is the case that many of the behaviours required in a designer and other tools implemented using code generated from the domain model, require one to walk the graph as a tree (and often in different ways). Examples include: deletion behaviour, how a model appears in an explorer, how it gets serialized in XML, how constraint evaluation cascades through a model, and so on. We have also found that although the trees required for each of these can be subtly different, they all seem to be some variation on some common, core tree. So we have chosen to make one tree central in the visualization, and have editing experiences for defining variants from this. At the moment, the only variant supported is the definition of deletion behavior.