Conceptual modeling
We use the Ampersand language to make domain models. A domain model is a conceptual model of a domain. It is a representation of the domain's concepts, relationships, and constraints. It is a way to describe the structure of a domain, the business processes that take place within it, and the rules that govern it.
We use the terms "conceptual model" and "domain model" interchangeably because we will always apply this technique to a specific domain.
Why bother?
Domain modeling is used for various purposes:
- To explore unknown domains. The act of making domain models is an efficient way to familiarize yourself with a new domain and to unravel jargon.
- To define the boundaries of individual services. A domain model should make these boundaries clear, to develop components as independently as possible.
- To avoid misunderstandings over terminology in a project with multiple stakeholders. A terminology list does not always suffice in practice. A domain model should consolidate consensus and make misunderstandings explicit and debatable before they do harm.
- Learning. A learner must familiarize herself with new words and specific phrases. Making a domain model improves both the speed and depth of learning.
The Ampersand way of conceptual modeling is a traditional approach where a conceptual model is built for a chosen domain. The Ampersand approach is particularly valuable when:
- Your model needs to be interpreted by a computer to create specific useful artifacts, such as a data model, a prototype implementation, or documentation.
- Your model has an interpretation in natural language, which you can use to standardize and unify the language of the business.
What is a conceptual model?
A conceptual model consists of concepts and relations that describe the language structure of a domain and comprises the constraints that govern it.
| Component | Description | Example |
| Concepts | The fundamental entities or ideas within a domain. | In an e-commerce domain, concepts might include product, customer, and order. |
| Relations | Relations describe how concepts are related to each other. | For example, the relation orders can represent facts about which customer has placed which order. |
| Language Structure | The specific vocabulary and terminology used to describe the concepts and relations. A conceptual model helps ensure consistency and clarity in how people communicate about the domain. | |
| Constraints | Rules that govern the behavior of the domain. They specify limitations or conditions that apply to concepts and relations. | Examples of constraints in e-commerce include a product must have a name and price, and a customer must have a unique identifier (e.g., email address). |
Example: a conceptual model in Ampersand
A conceptual model may have many different representations. Here is an example of a conceptual model in Ampersand source code:
CONTEXT Enrollment IN ENGLISH
RELATION takes[Student*Course]
RELATION isPartOf[Module*Course]
RELATION isEnrolledFor [Student*Module]
RULE ModuleEnrollment: isEnrolledFor |- takes;isPartOf~
ENDCONTEXT
The following diagram represents the conceptual model visually. Note that this diagram does not represent the constraint:
The following diagram shows the conceptual model as a data model:
Constraints are rarely visualized in graphical representations of conceptual models. Yet, they are an essential part of the conceptual model. They are the rules that govern the domain.
First validation
Can your conceptual model represent facts in your domain? This is your first step in creating a conceptual model. The following Ampersand code represents eight facts in the domain of enrollment:
CONTEXT Enrollment IN ENGLISH
POPULATION takes[Student*Course] CONTAINS
[ ("Peter", "Management")
; ("Susan", "Business IT")
; ("John", "Business IT")
]
POPULATION isPartOf[Module*Course] CONTAINS
[ ("Finance", "Management")
; ("Business Rules", "Business IT")
; ("Business Analytics", "Business IT")
; ("IT-Governance", "Business IT")
; ("IT-Governance", "Management")
]
ENDCONTEXT
Among others, this code represents the fact that Peter takes the course Management and the fact that the module IT-Governance is part of two courses: Business IT and Management.
We advise strongly to invent 2-3 facts for every relation in your domain and to represent them in Ampersand code, to verify that your relations can represent the facts you intend them to represent .
Steps
Here is a summary of the things you do.
Start with an informal analysis of the business, defining
- stakeholders, such as: sales rep, student, DBA, inspector, etc.
- relevant areas of expertise, such as insurance, security, legal, management, etc.
- business functions, such as invoicing, applying for a job, computing rates, etc.
In essence, this step yields three lists. You obtain them by studying documentation and talking to people as you scope your work.
Formalize concepts and relations to reconstruct the language of the business. Validate that language with your stakeholders, creating consensus over terms and phrases. Your goal is to define the smallest agreed language in which agreements can be expressed.
Use this language and adapt it when needed:
- to generate visual representations of your domain model (letting your computer do the drawing work);
- to resolve language-based misunderstandings in your team;
- to generate a database, either for prototyping or production purposes;
- to define, verify and validate services that constitute your application;
- to audit designs;
- to generate documentation (letting your computer do a lot of writing);
- other purposes, that arise incidentally.
In essence, this step yields a conceptual model of your domain. In some cases, however, the act of modeling is more important than having the model.
draw boundaries to define bounded contexts. Identify reusable patterns. Identify entities, attributes, aggregates and services for each bounded context. Assign developers, stakeholders, product-owners to develop each bounded context further.
Informal analysis
Formalize concepts and relations
Once you have an informal picture of the domain, you reconstruct its language as concepts and relations. This section is a practical instruction for harvesting concepts from your sources and testing whether a candidate is really a concept.
Harvesting candidate concepts
Read your authoritative sources (do not just search them) and collect the nouns that denote things in the domain. For each candidate, note where you found it and write two or three basic sentences — facts about two individual atoms — that use it. If you cannot phrase a single fact about two individual things, the candidate is probably a general statement, not a concept.
The TIPI test
A concept is a set of atoms. Before you accept a candidate, ask the four TIPI control questions (a Dutch mnemonic: Telbaar, Instantieerbaar, Permanent, Identificeerbaar — countable, instantiable, permanent, identifiable):
| Criterion | Control question | Reject when… |
|---|---|---|
| T — countable | Can you count its atoms? | It names a mass, not countable things — e.g. water. Choose a countable meaning such as body of water ("the IJsselmeer"). |
| I — instantiable | Which atoms does your concept have? Give examples. | The candidate is itself an instance — e.g. Amsterdam, King Willem-Alexander. These are atoms of City, Person. |
| P — permanent | Do its atoms stay in this concept forever? | Membership can change — a Student may become an Employee. Then model Person with relations student and employee. A name can change, so it is a relation name[City*Name], not the concept Amsterdam. |
| I — identifiable | Can you tell its atoms apart? | Atoms are indistinguishable (countable but not identifiable, like identical coins). Attach a label to make them identifiable. |
A further rule: a concept must not represent the context itself. If the whole system already concerns one association PHV, then PHV is the context, not a concept within it.
When a candidate fails Permanent or Instantiable, it is usually a relation or an attribute, not a concept. The right choice often depends on context — always ask "in which context?".
Reusing an existing standard
If your domain already has an authoritative vocabulary (a standard such as IFC, a registry, or a law), match each validated concept semantically to that standard — the same notion may carry a different name — and adopt the standard's name and definition. Copy definitions verbatim from the source, but trim passages that describe the standard's internal machinery rather than the business meaning. Invent nothing, and omit a definition where the source is silent.
Q&A
Q: Is Amsterdam a concept? A: No. Amsterdam is itself an instance, so it is not instantiable (saying "34 Amsterdams" is meaningless). It is an atom of the concept City. Being a proper name is, by itself, not a reason — proper names can be perfectly good atoms.
Q: Is Student a concept?
A: It depends on the context. If a student can later become an employee, Student is not permanent — model Person with a relation student. If, in your context, "once a student, always a student", then Student may be a concept.
Q: Is water a concept? A: Not as a flowing mass — it is not countable. Choose a countable meaning, such as body of water ("the IJsselmeer", "the North Sea"), which is countable and identifiable.
Q: A candidate is countable and identifiable, but I cannot make instances of it. Concept or not? A: Not a concept. All four TIPI criteria must hold. If you cannot instantiate it, it is either an instance itself or a statement about the context.
Q: In lastName[Person*Name], should Name be a concept?
A: Yes — names are countable, instantiable, permanent and identifiable. That a person's name can change does not threaten the concept Name; it means the relation lastName may change, which is exactly why it is a relation and not a permanent property of Person.