At InferData, we always build domain models before progressing to system modeling. I've noticed that this is becoming more and more a trend in the industry although, what the various methodologies/methodologists define to be a domain model seems to vary.

We've been using domain models to understand a problem area. Our domain models are quite abstract, but they may be very precise.

In general, we define domain models using two aspects.

The first is a structural aspect. That is, we describe what the interesting objects are and how they relate to each other. The notation we use for this is UML class diagrams, although, we only use a limited part of the notation (Classes, Attributes, Associations and Inheritance).

The second aspect defines the dynamics of the domain (aka behavior). We describe the behavior as the effect that various events have on the objects. We describe the behavior using observational semantic (that is, we "imagine" that we have observed a change to the objects in the domain and we're describing this change. This is quite different from many other methods where the specifier thinks more like this "If I was to apply this action in the domain, the domain state will change this way").

It turns out that the observational semantic has several advantages. The most important of which (IMHO) is that it seems to be much easier to combine fragments of specifications.

This combinability (I wonder if that word will pass my spell checker :-)) makes it much easier to define and combine views.

I think the use of views in domain models may be a great thing moving forward. I can see us develop a set of orthogonal views that then can be combined into more complex models... More on that later...