A domain model is a suite of coordinated artifacts for formal description of the environment, requirements, functions, architecture, and operating constraints of computer systems in a particular application domain. The abstractions in a domain model provide precise and comprehensive terminology for the domain. Domain modeling is the act of constructing and improving a domain model.
There is a fundamental assumption behind domain modeling: application domains that seem different to users and to other branches of engineering are 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.
All software-engineering techniques, from requirements elicitation and validation to code testing and maintenance, either require or benefit from formal, abstract descriptions of the system. Yet these descriptions are notoriously difficult to produce for real systems. They are usually missing or trivialized, which undermines all other engineering efforts. (A trivial description belabors the obvious, while ignoring the aspects of the system that make it challenging to build and maintain.)
The purpose of domain modeling is to make good formal descriptions readily available. The domain model provides terminology, templates, and tools that can be reused to model any system in a large family. Whatever form the domain model takes, it must embody good decisions about what is important or difficult, so that the result is 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. We are also good at making formal descriptions analyzable, so a domain model makes automated verification practical.
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. Web services and integrated development environments attract the right kind of attention, and are well on their way to having excellent domain models. These domains have a common characteristic: software-engineering researchers use them and build them, so they contribute their collective expertise to the living models of these domains.
For other complex application domains, such as medical technology, networks, energy grids, transportation, and financial services, 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.
Academic researchers in computer science do not do modeling of these industrial domains because they lack steady funding dedicated to a particular domain, because they lack conduits to domain experts, and because they lack interest in it. Inter-disciplinary research is usually under-recognized and under-rewarded.
Many people seem to believe that practitioners in these industries should do the domain modeling. But they do not and can not work on domain modeling, for many reasons:
Formal methods flourish when good domain models exist, because they are easy to use and cost-effective. If there is no model for a domain and therefore no tools adapted to it, formal methods are almost impossible for practitioners to use.
The consequences go far beyond the fates of certain academic researchers. Our software-driven world needs formal methods for safety, security, social transparency, productivity, and a hundred other reasons. For many of these concerns, the use of artificial intelligence is a big step backwards.
I hope that software-engineering researchers will realize soon that the domain-modeling gap is critical. They must understand that domain modeling is their responsibility, and take steps to remove the barriers to work of this kind.
To give a narrow example, researchers need an intellectual community and appropriate standards for evaluation of contributions. Intellectual communities could be organized around domain-specific workshops and conferences, which are publicized to relevant research communities outside computer science. Appropriate standards would reward progress on representing ever-bigger pieces of the domain, or on representing the same pieces of the domain better. They would not reward covering old ground with new notation, if it makes no other contribution.