A domain model is a suite of coordinated abstractions for formal description of the environment, requirements, functions, architecture, and operating constraints of computer systems in a particular application domain. Domain modeling is the act of constructing and improving a domain model.
The fundamental assumption behind domain modeling is that application domains that seem different to users and to other branches of engineering may be inherently different from the perspective of computer science as well. There is no set of computing abstractions that is equally good for all of them.
Essentially all disciplined techniques for engineering software, from requirements elicitation and validation to code testing and maintenance, either require or benefit from the formal descriptions enumerated above. Yet these formal descriptions are notoriously difficult to produce for real systems. Because they are so difficult to produce, they are often missing or trivialized, which undermines all other engineering efforts.
The purpose of domain modeling is to make formal description tractable and routine rather than overwhelming and unpredictable. It achieves this by providing templates, examples, or languages that can be adapted or used to describe a family of similar systems. Whatever form the domain model takes, it must embody good decisions about how to describe the domain, so that the result is concise, comprehensible, and useful for many purposes.
Once there is an accepted model of a domain, there is a possibility of incremental, communal improvement in all aspects of software development (not to mention further improvement in the model). The effect of an accepted domain model on architecture and implementation is particularly striking, because computer scientists have proven so good at taking computational abstractions and making them efficiently executable.
Because of their success, domains with well-established models tend to enjoy reusable architectures, reusable components, and a great deal of automated code generation. The oldest examples of such domains are those of compilers and databases.
For application domains that attract the interest and participation of individuals, some progress (at least at the architectural level, if not at the level of requirements) seems inevitable. People need a common architectural model so that they can pool their development efforts. Open-source projects provide communities in which incremental improvements can accrue. And of course, the correctness of such systems is not usually a critical issue.
Currently, Web services are attracting the right kind of attention, and are well on their way to having excellent domain models.
For other complex application domains upon which large industries are based, such as those in medical technology, transportation, financial services, telecommunications, and manufacturing, there is more cause for concern. Little progress is visible. There is a danger that no one will do the right kind of work, no matter how badly it might be needed.
Researchers in computer science tend not to do domain modeling because they lack steady funding dedicated to a particular domain, because they lack conduits to domain experts, and because they lack interest in it.
A "practitioner" is a person whose job it is to produce real computer systems in support of industry, within the constraints of schedules and budgets. Currently, experts in an application domain are almost always practitioners.
Practitioners do not and can not work on domain modeling, for many reasons:
By now, the problem should be clear--if neither researchers nor practitioners do domain modeling, who will?
The solution seems equally clear: researchers should be doing domain modeling. They have the time, the expertise in formal methods, and the inclination to think in abstract terms.
To facilitate this, it is important to eliminate the obvious obstacles. Researchers need steady domain-specific funding, and frequent contact with practitioners, from whom they can get both domain expertise and feedback. Researchers must have the opportunity to become domain experts.
Researchers in industrial laboratories have always had these advantages. However, recent years have seen a very dramatic drop in the number and size of industrial laboratories doing research in computing, at least in the U.S. This drop makes it all the more important to increase the quantity and quality of collaborations between academic research and industry.
The final obstacle is that researchers may not be very interested in domain modeling. This is because certain aspects of the research culture prevent intellectually stimulating discourse. Fortunately, these aspects are malleable, so that change is feasible, if not necessarily easy.
For researchers to make progress on the modeling of some domain, they need an intellectual community and appropriate standards for evaluation of contributions. Intellectual communities would be organized around domain-specific workshops and conferences. Appropriate standards would reward progress on representing ever-bigger pieces of the domain, or on representing the same pieces of the domain better, or on comparing different representations to see which is better. They would not reward covering old ground with new notation, if it makes no contribution to understanding the domain.
These needs are in some opposition to the current technology-oriented organization of communities within computer science. The technology orientation has its own motivations, so we must find a way to balance the two orientations. Certainly there is benefit for everyone in bridging the gulfs between technologies, and domain modeling might provide an appropriate focus for doing so.