I’m not going to give you a hard ‘My answer is the only answer and is correct in all circumstances’ because as is often the the case, there is seldom a single answer that holds true always.
Instead I will explain a point of view that has served me well:
A Domain Object is a representation of information in a format that is convenient for the Domain making use of that information. Collectively Domain Objects form a Domain Model.
Great, that was easy. Now we need to understand what a Domain is.
From the Oxford Dictionary:
- An area of territory owned or controlled by a particular ruler or government.
‘the French domains of the Plantagenets’
- A specified sphere of activity or knowledge.
‘the country’s isolation in the domain of sport’
Late Middle English (denoting heritable or landed property): from French domaine, alteration (by association with Latin dominus ‘lord’) of Old French demeine ‘belonging to a lord’ (see demesne).
You may be wondering why I include the English definition of a word when explaining it from a computer science point of view?
My understanding of Domains in software architecture is derived from the second meaning above: “A specified sphere of activity or knowledge”.
In any well designed software system you should be able to identify distinct areas of responsibility which could be thought of as belonging to a specified sphere of activity or knowledge.
In the hypothetical software system shown here, I have highlighted some possible domain areas.
Each area is likely to have it’s own representation of the information appropriate to it’s primary use.
For example in the Network Transport domain, the data may be represented in XML. A format convenient for transporting over a network.
The client application might be written in Java. It would be more convenient to work with data encapsulated in Java Objects. So it has a different domain representation.
You will notice the Server end of the system has two different Domains (Account information and Contact information) this is quite common in larger enterprise systems. There may be many distinct systems running very different operating systems and having very different representations of information. Each of these can be thought of as a Domain.
In actual fact it is quite likely that the client application will have many different domains inside it, depending on the complexity of the application. It extreme cases you may even have several domains within a single feature.
You should also notice the services that have two or more different domains “overlapping” them. This hints that something special is happening. And indeed it is.
These services have to translate from one domain representation of information into another. This process is called Domain Transformation and involves consuming domain objects in one domain format and producing new domain objects in the other domain format. Sometimes combining domain objects from several domains to produce an object that is convenient for the consuming domain or vice-versa.
Often the source or destination domain objects may be a special type of object called a Data Transfer Object. See my article “How to know if you are a Data Transfer Object” for a little more information on DTOs.