Open a mature codebase and grep for Customer. In billing, it means an active, paid account; in support, anyone who has sent an email; in analytics, a deduplicated household. The bug isn’t in one module, but in three teams misunderstanding they’re referring to the same thing.

A software ontology is a clearly defined, shared model of a domain that includes concepts, meanings, and relationships, documented and integrated with code. This article explains its role in Domain-Driven Design (DDD), why it exists, and how it functions as a mental model.

What a software ontology actually is

An ontology answers three questions: what concepts exist, what they mean, and how they connect. DDD assigns concrete names to these answers. The concepts and meanings form the ubiquitous language. Their scope is the bounded context. The structure linking concepts and boundaries is the set of aggregates and relationships.

A software ontology combines a vocabulary, boundaries, and a structural model, maintained as a single entity and reflected in code.

The word “ontology” in philosophy denotes the study of existence and also refers to formal artifacts such as the Web Ontology Language (OWL) and the Resource Description Framework (RDF) in the semantic web, which are designed for machine reasoning. This article does not use them. A DDD ontology is pragmatic, aiming to promote human agreement and software design, not to power reasoning.

Why the idea exists

Software is a translation problem. Domain experts use business terms like dunning and chargeback; code uses technical language like nullable columns and foreign keys. Features translate between these, but meaning often leaks at boundaries.

The Customer example shows leakage: teams translated the domain into code without a shared model, resulting in three correct but contradictory translations. This went unnoticed until a report counted the same person three times.

An explicit ontology prevents drift by consolidating concepts into a single source, making contradictions clearer rather than hidden as local choices. It aims to be a unified source of meaning for humans and code.

How it works as a mental model

A map is a good analogy. It’s not the territory itself but a simplified, shared representation that helps a group navigate without having to memorize the landscape. A software ontology is a domain map with the same three parts as any good map.

graph TB UL[Ubiquitous Language: the legend] BC[Bounded Context: the sheet boundary] AG[Aggregates and relationships: the roads and regions] UL --> BC BC --> AG

The ubiquitous language is the legend that assigns each symbol a single meaning for consensus, such as a blue line. In code, each domain term has one definition used across classes, tables, and API fields, sharing vocabulary between map and territory.

The bounded context is the boundary of a sheet, where the Customer bug activates. An ontology doesn’t require “customer” to mean the same company-wide; this confuses. Instead, it specifies that within a sheet, boundaries are local. A bounded context defines where a word has a clear, single meaning.

The aggregates and relationships are the roads and regions: the structure. An aggregate groups concepts that must stay consistent and describes the rule that connects them. Relationships are labeled lines between concepts, each a sentence in the ubiquitous language (“an invoice bills a subscription”). This is where the ontology stops being a word list and becomes a model with shape.

Read the three layers from the top down: agree on words, fence them into contexts where they hold, then give structure. An ontology is a shared map of meaning, scoped to a context and kept true against code.

How it relates to things you already have

Most teams already own something ontology-shaped. Seeing the difference is what makes the concept click.

A glossary is the closest neighbor and most common confusion point. It is simply words and definitions. An ontology expands on this by adding boundaries (where meanings hold) and structure (relationships and consistency among concepts). A glossary explains what “invoice” means. An ontology further specifies that an invoice belongs to one billing period, its line items sum to its total, and that “invoice” in Billing differs from “receipt” in Support.

A data model, the entity-relationship diagram behind the database, looks similar enough to mislead. It shows how information is stored and queried efficiently, while the ontology explains what concepts mean and how they behave. An aggregate isn’t a table; it may span multiple tables, and a table can serve multiple concepts. The models diverge intentionally because storage and meaning considerations optimize different aspects.

A domain model is a team’s understanding of its problem space. An ontology makes that understanding explicit, named, written down, and shared, so it exists outside any one person’s mind.

The Fundamental Software Concepts post explains the vocabulary used in an ontology, providing context for how these pieces fit together.

What it costs and where it fails

An explicit ontology is not free, and treating it as pure upside is how it dies.

It has maintenance costs. A drifting model is worse than none since people trust it falsely. An unedited wiki ontology decays in a quarter. Survivors exist in version control, reviewed with code, so the model and system evolve together.

It encourages over-modeling, as a senior team might spend weeks classifying concepts the next feature won’t use. The key is to model only the immediate slice, not the entire envisioned future.

Sometimes, a glossary suffices. A small team with a shared language and no contested terms doesn’t need complex contexts or aggregations. The ontology becomes valuable when meaning varies across teams or contexts, or when relationships have rules requiring enforcement. Below that point, a simple list of definitions is enough.

Common misconceptions

A few beliefs reliably send teams in the wrong direction.

“It is just a glossary.” A glossary lacks boundaries and structure. It can’t clarify that “customer” means different things in different contexts because it doesn’t understand context. The Customer bug exploits this missing dimension.

“There should be one ontology for the whole company.” This is the costliest mistake because it sounds rigorous. A single global model mandates one definition of “customer” for varied team needs, collapsing under contradictions. Meaning is local. A healthy ontology consists of bounded contexts with explicit translations, not a top-down dictionary.

“It is documentation.” Documentation describes a system post-fact, while an ontology is a model the code follows. If treated as source, reviewed and versioned, it remains accurate; if treated as documentation, it drifts.

“It is the database schema.” The schema affects storage and query performance, while the ontology affects meaning and behavior. They reference the same domain, but forcing them to be identical degrades both.

What an ontology means for AI agents and language models

A large language model (LLM) has read the public internet, knowing the general meanings of “customer,” “invoice,” and “subscription.” It hasn’t read your domain and fills with the average meaning from many codebases, not your specific billing context.

That is the Customer bug from the opening, relocated. The leak now runs between your domain and a model assuming the generic definition is correct.

An explicit ontology bridges the gap by placing the ubiquitous language, bounded contexts, and relationships where the model can read them. Its output then grounds in your meaning rather than statistical averages. The model stops treating “customer” as anyone who sent an email and begins using your system’s definition.

An AI agent that reads files, runs commands, and edits code gains more. Without a map, it explores blindly: it retrieves a term, guesses the meaning, and acts. The ontology provides named concepts, boundaries, and labeled relationships to reason over before making changes. It’s the same map humans use, now accessible to a tool.

The earlier distinction softens here. A DDD ontology is pragmatic, meant for human agreement rather than formal reasoning with OWL or RDF. When an agent reads it, the ontology also functions for machine reading. The artifact remains the same; its audience expands.

Maintenance costs increase as a stale ontology misleads a person, who instinctively doubts wrong definitions. A model lacks this instinct, so a drifted ontology causes it to confidently generate plausible but incorrect domain code. Maintaining true ontology against code ensures it’s safe to give to a machine.

The mental model to keep

A software ontology is a shared map of a domain, linking words to meanings with boundaries and structures that give concepts shape and rules. It is built for human agreement, kept true against the code, and its absence is invisible until teams interpret the same customer differently.

That is the test of whether you need one. If everyone shares the map, the model is in their heads, and the cost isn’t worth it. Once the map differs among people, the drift has begun.

Next Steps

References

  • Domain-Driven Design by Eric Evans, the source of the ubiquitous language, bounded context, and aggregate concepts used throughout.
  • Diátaxis, the documentation framework this explanation follows.