For example, in the knowledge engineering/knowledge representation community coming out of an AI background, domains are generally understood to be problem areas within the "real world": diagnostic procedures, heuristics for interpretation of oil-drilling data, etc. Expert systems were first applied in areas that had not been previously believed amenable to software support; thus for the most part this community had no need to distinguish "real-world domain" knowledge from software developers' knowledge about the systems that support practitioners in these domains.
For this community, domain analysis for software reuse could be described as knowledge modeling for domains drawn from software developers' expertise in building particular classes of applications. DA would thus specialize general knowledge modeling techniques to address specific issues in capturing and representing knowledge about software systems as opposed to other kinds of domains: e.g., different data gathering methods, representation issues, etc.
This analogy breaks down, however, because in the software system context the "real-world" sense of the word domain does not disappear. In most cases, software developers only have (and only need to have) a partial view of the knowledge held by real-world practitioners that will use the systems. The job of understanding that real-world knowledge is placed at the door of the requirements analyst. Sometimes that knowledge is called the "problem space."
In a sense, software-intensive domains include a "cascaded" series of domain frames or context: the real-world knowledge the end-user has, the architectural or implementation knowledge that the software developer has, and possibly other levels of knowledge as well. So, in the case of an accounting program, financial knowledge is layered and embedded within knowledge of how accounting software is typically structured and written. When we speak of domain analysis in such a context, some people interpret this as modeling the "real world" within which financial knowledge is needed, others as modeling the commonality and variability across a given set or class of software systems supporting those real-world functions.