Domain models are the first step in going from a set of requirements to actual software code. Typically a domain model will be built by the system designer or software architect. Domain models are not part of the requirements but can be validated by people writing requirements to ensure that the relationships make sense.
Domain models are the first step in the static modelling side of the ICONIX Process. ICONIX is seen as a “heavy design” process these days with many agile projects moving away from ICONIX, and in particular the authors of the C4 model have been very critical of ICONIX. However there is still some room for components of the ICONIX process as part of agile software development, and one of those components is the Domain model.
Building a Domain Model
The first part of building a domain model is to build a project glossary. I covered how to build a project glossary as part of the article What is a Project Glossary?
The project glossary is a list of definitions in use in a project. For example, we extracted this part of a project glossary from our functional requirements:
A domain model is created from the definitions of the requirements document — by extracting all of the nouns from the project glossary which become the highest level components of the system. So, for example, there might be boxes on the domain model for “customer”, “administrator”, “profile”, “product”, “subscription”, etc.
Domain models contain links between these words that explain to the developers and the business people how these words relate. The most commonly used links are:
- (straight line link) — these two objects are related in some way — for example a “customer” is related to a “transaction”.
- (arrow head link) — one object “is a type of” another object. For example a “customer” is a type of “user”.
- (diamond head link) — one object “is contained in” another object — or from the other object’s point of view one object “has many” other objects. So for example one “subscription” has many “payments”.
In the domain model, we aren’t concerned with lower level concepts, and in particular we aren’t concerned with “attributes” — the data that makes up the domain model objects. For example, on our domain model we will see a Customer, but we aren’t interested in seeing a customer number, a customer name, the account balance, or any of those smaller details that go into making up what a customer is. We are only interested in the top level Customer object.
Domain Models for Requirements Writers
If you’re a requirements writer (product owner or business analyst), then the software architect should be able to show you and explain to you the domain model. The domain model will contain all of the high level objects in the system, and some connecting lines relating these objects together.
If you read a domain model and the words on it make no sense, or the connections seem incorrect (for example if the domain model contains a relationship like “one customer has many administrators”) then question the software architect on that.
Domain Models for Developers
A domain model is the highest level static model of a system. Domain modelling in software architecture is a topic covered extensively in many books and topics, for example in the ICONIX process.
These domain model objects become the business logic classes of the system, encapsulating the highest level data objects of the system.
How might a developer use a domain model? There are some examples, depending on what type of development you are doing:
- In a micro-service based architecture, each component in the domain model may become an individual micro-service. If the domain model contains very closely related objects then these can be grouped together into a single micro-service, however each domain model object should be a separate module within that micro-service.
- In a more traditional service based architecture with larger services than micro-services, then the domain model objects can become modules within the software.
- Are you building an MVC based system? I’ll explain in more detail in another article why I believe that to be a bad idea, but at the very least you can build controllers to handle the functionality of domain model objects.
- In a database structure, looking at the domain model is a good way to visualise the structure of your database. Each domain model object may become one or more tables in the database.
- You may wish to break down the domain model into a class diagram (this is really software design, not software architecture), if for example you need to be able to communicate to less senior developers how you want the code to be structured. Each domain model object will become one or more related software classes.
Example Domain Model
Here is an example domain model extracted from an imaginary transaction handling system — maybe part of an e-commerce package.
Reading this from the top down:
- There are users and there are sites.
- A customer is a type of user. A customer is associated with a site.
- A site has many gateways.
- A customer has many transactions.
- Each transaction is associated with a payment token. A payment token is also associated with a customer and a gateway.
- A payment is a type of transaction.
- A refund is a type of transaction.
This, simplistically, becomes the top level data model of the system, and each of these domain model objects becomes a micro-service, a class or group of classes within the system.