In general domain models in software engineering are represented in UML and most UML class diagram constructs can be translated to an ontology. I have written about this here.
Benefits of ontologies for software engineering
The benefit of translating a UML class diagram to an ontology is that since the ontology is backed by artificial intelligence reasoning procedures, it can determine whether there are logical inconsistencies in your UML class diagram. Such logical inconsistencies are difficult to find via typical unit testing (once the class diagram is implemented in code) since the logical inconsistencies typically arise from the relations between classes rather than a single class which is usually the focus of unit testing. Moreover, besides highlighting inconsistencies, ontologies can provide reasons for why an inconsistency happened, which is helpful to eliminate the inconsistency.
Why ontologies are not used extensively in software engineering
If ontologies are so helpful, why are they not used extensively in software engineering? I think there are 3 main reasons (in my opinion):
(1) In my experience very few people seem to be aware of ontologies so that option is just not on their radar to start with.
(2) Many companies forgo requirements engineering completely or do a watered down version of requirements engineering due to time to market pressures. Hence, it is often up to the developer to "spec" the requirements and when left with the choice to code or draw a UML class diagram many developers will prefer writing code immediately.
(3) Tool support is a problem. Though there are a number of tools to create ontologies and reason over them, there are no tools for translating between UML and ontologies. Even in the absence of tools, one can do the translation by hand. One certainly has to become knowledgeable about mathematical logic underlying ontologies, which is not trivial, but the translation between UML and ontologies is well understood and there are sort of "patterns" for doing the translation. So the absence of tools for the translation presents a challenge, but it is not an obstacle. It does slow one down however.
When to use ontologies for software engineering
Taking into account the limited skills in ontologies and limited tool support I would say it makes sense to use it where the business logic is complex and/or the impact of getting the business logic wrong will have severely negative consequences for the business. As an example, I have helped a business analyst to design the domain model for the costing model of a company where they had in excess of 2000 permutations. This number of permutations made it very difficult for the stakeholders to think about the problem.
Part of the problem is that stakeholders often have fuzzy concepts in their mind with many concepts overlapping. The job of a business analyst is to untangle these concepts, but even for an experienced business analyst it can be difficult to articulate exactly which concepts in a domain model are problematic and why. The reasoning and explanation services of ontologies can give helpful insight in this regard.
In designing the ontology for the costing model, the inconistencies helped stakeholders to realize that their concepts are fuzzy and the explanations helped the business analyst to understand in what why the concepts are fuzzy and to propose alternatives.
Why you should consider having a domain model outside of your code
When the domain model can only be found in the code, it is only accessible to the software developers. It is not accessible to business analysts, testers, project managers, users, business stakeholders and sponsors. The biggest benefit to having a domain model outside of the code is that it enables a shared understanding of a system for all stakeholders, not just for software developers. Such a shared domain model fosters a shared understanding which results in less time being wasted due to miscommunication because of the need to translate between "developer terminology" and "business terminology".
UPDATE 20180513 - Wrt comment on modelling
In this question on stackoverflow, the accepted answer claims ...OWL purpose is not modelling...It should be distinct from any software engineering process... claiming that ontologies are better for 'knowledge representation' rather than 'data modelling'. What is the main distinction here?
The purpose of OWL is to describe concepts and the relations that exist between concepts. As such OWL can be seen as a conceptual modelling language. What is conceptual modelling? In my dissertation I have defined it as follows:
Conceptual modelling is the act of documenting a domain to facilitate understanding and communication between stakeholders. The artefact resulting from the conceptual modelling activity is called the conceptual schema. A conceptual schema is an abstraction of the conceptually relevant aspects of a
domain from a particular point of view. Implementation specific details are
excluded from a conceptual schema. A particular domain may be described by a
number of different conceptual schemas.
UML is a general-purpose modelling language designed for use in the analysis, design and implementation of object-oriented software systems. Object-oriented analysis is distinguished from object-oriented design in that the focus of object-oriented analysis is to elicit and describe the classes and objects that form part of the problem domain, while the focus of object-oriented design is on designing the software solution consisting of objects and related collaborations that would fulfill the requirements. Thus, object-oriented analysis is strongly related to conceptual modelling while object-oriented design is strongly related to the implementation details of realizing the conceptual schema in code.
The key difference
OWL can be used to define the conceptual model/domain model of your software system (object-oriented analysis). However, OWL will be a bad choice for defining the implementation details of your software system (object-oriented design). Why? The implementation of a software system aims to realize the conceptual model while meeting various architectural quality attributes like performance, scalability, integratability, security, etc. These implementation details fall outside the scope of OWL. This is part of the reason why I believe the conceptual model/domain model should be available outside of the code base. In aiming to meet various quality attributes, the domain model is often obscured in the code base.
