Ontologies and Domain-Driven Design: What's New, What Isn't, and Why AI Cares

Ontologies are popular again, mostly because of artificial intelligence (AI) agents. A developer who knows Domain-Driven Design will find much of the idea familiar. This post covers what the two share, where they differ, and why the interesting work now is letting AI programs use your existing business model safely.

Two ways to describe a business

Both ideas start from the same goal: describe a business in its own words, not in database tables. You name the things the business talks about (customers, orders, products), say how they connect, and write down the rules.

The difference is what each one does with that description:

• An ontology says what exists and how things relate. It is a description that people and programs can read, share and draw conclusions from.
• Domain-Driven Design also says how things behave. It turns the description into code, and that code refuses to break the business rules.

The diagram shows the overlap. The shared part in the middle is large, which is why the two ideas feel so close.

⤢ enlarge

The next two sections look at each idea on its own, starting with the one most developers already know.

What Domain-Driven Design gives you

Domain-Driven Design (DDD) is a way to build software around the business it serves. Eric Evans described it in his book Domain-Driven Design, and he later published a free summary of its patterns, the DDD Reference. In DDD, the model of the business is code, and that code protects the business rules every time something changes.

These are the building blocks you will meet most often:

• Ubiquitous language. The developers and the business experts use the same words for the same things, in meetings and in code. If the business says "cancel an order", the code has a cancel() method on Order.
• Entities. Things with an identity that lasts over time, like an order or a customer. Two orders with the same items are still two different orders.
• Value objects. Things defined only by their values, like an amount of money or an address. Two "10 euros" are the same thing.
• Aggregates. A group of objects that change together. All changes go through one main object. An order and its items form an aggregate: you change the items only through the order.
• Invariants. Business rules that must always be true, like "a shipped order cannot be cancelled". The aggregate checks them on every change.
• Domain services. Business operations that don't belong to one entity, like working out the shipping price for an order from several rules.
• Bounded contexts. One model is valid only inside a clear boundary. Martin Fowler's article on bounded contexts uses the word "meter" at an electricity company: it meant three different things in three parts of the company. So DDD gives each part its own model and translates between them, instead of forcing one model on everyone.

Here is a small order aggregate in TypeScript. Each rule lives inside the method that changes the order, so no caller can skip it.

type OrderStatus = 'PLACED' | 'PAID' | 'SHIPPED' | 'CANCELLED';

class OrderItem {
  constructor(
    public readonly productId: string,
    public readonly quantity: number,
  ) {}
}

class Order {
  constructor(
    public readonly id: string,
    private items: OrderItem[],
    private status: OrderStatus,
  ) {}

  addItem(item: OrderItem): void {
    // Invariant: items can change only before the order is paid.
    if (this.status !== 'PLACED') {
      throw new Error('Items can change only before payment');
    }
    this.items.push(item);
  }

  cancel(): void {
    // Invariant: a shipped order cannot be cancelled.
    if (this.status === 'SHIPPED') {
      throw new Error('A shipped order cannot be cancelled');
    }
    this.status = 'CANCELLED';
  }
}

The code says nothing about database tables. It speaks the business's language and enforces its rules. An ontology starts from the same place but goes in a different direction.

What an ontology gives you

An ontology is a precise, written description of the things in a domain and the relationships between them. The definition most people quote comes from Tom Gruber's 1993 paper, A Translation Approach to Portable Ontology Specifications: an ontology is "an explicit specification of a conceptualization". In plain words: you write down, in a precise form, how you see a domain. An ontology describes what exists and how it connects, so that different people and programs can share the same meaning.

Its building blocks are a little different from DDD's:

• Concepts (also called classes). The kinds of things in the domain: Customer, Order, Product.
• Properties. Facts about a thing, like an order's date or a product's price.
• Relationships. How things connect: a customer places an order, an order contains products.
• Constraints. Statements about what must be true, like "every order is placed by exactly one customer".

Here is the same shop as an ontology. Each box is a concept and each arrow is a relationship.

⤢ enlarge

Ontologies usually live in standard formats, not in application code. The most common one is the Resource Description Framework (RDF), from the World Wide Web Consortium (W3C). RDF stores every fact as a triple: three parts, a subject, a relationship (RDF calls it the predicate) and an object, like "Customer places Order". On top of RDF, the Web Ontology Language (OWL) adds ways to define concepts and relationships with an exact meaning that programs can check.

The diagram above, written in Turtle (a text format for RDF), looks like this. The @prefix lines are short names for long web addresses, and a means "is a".

@prefix shop: <https://example.com/shop#> .
@prefix owl:  <http://www.w3.org/2002/07/owl#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

shop:Customer        a owl:Class .
shop:Order           a owl:Class .
shop:Product         a owl:Class .
shop:Payment         a owl:Class .
shop:PaymentProvider a owl:Class .

shop:places      a owl:ObjectProperty ; rdfs:domain shop:Customer ; rdfs:range shop:Order .
shop:contains    a owl:ObjectProperty ; rdfs:domain shop:Order    ; rdfs:range shop:Product .
shop:paidThrough a owl:ObjectProperty ; rdfs:domain shop:Order    ; rdfs:range shop:Payment .
shop:processedBy a owl:ObjectProperty ; rdfs:domain shop:Payment  ; rdfs:range shop:PaymentProvider .

This file is data, not a program. Any tool that reads RDF can load it, combine it with descriptions from other systems, and infer new facts (work out facts that nobody wrote down). For example, if a program knows that someone placed an order, it can conclude that this someone is a customer. That is the strength of an ontology: one shared meaning that crosses system boundaries.

The two side by side

With both ideas explained, this table sums up the differences:

Question	Domain-Driven Design	Classic ontology
What is it for?	Software that is easy to maintain and speaks the business's language	A shared understanding of the domain
What are the building blocks?	Entities, value objects, aggregates, domain services	Concepts, properties, relationships, constraints
How much does one description cover?	One bounded context	Can connect concepts across many systems
Does it name the business's things and how they connect?	Yes	Yes
Does it stop a program from breaking a business rule?	Yes	No
Can a program infer new facts from it?	No	Yes

The rule row is the important one. An ontology can state that "every order is placed by exactly one customer", but it does not run when a program changes an order. It describes the rule. DDD enforces it. Separate tools can check stored data against an ontology's constraints, but that check is not part of the ontology, and it only runs if you call it. The order example shows this well: the ontology can say that an order has a status, but "a shipped order cannot be cancelled" is behaviour, and behaviour lives in the cancel() method.

Operational ontologies: adding behaviour

Some companies now build ontologies that do more than describe. Palantir is the best-known example. Its documentation calls its Ontology "an operational layer for the organization": it connects a company's data to the real-world things that data is about, like equipment or customer orders.

Palantir's Ontology has these parts (as of October 2026):

• Object types, properties and link types describe the things and how they connect, like a classic ontology.
• Action types define a set of changes to objects that a user makes in one go, like "cancel this order".
• Submission criteria are the conditions an action must pass before it runs. They check the user, the inputs and the situation, and they explain to the user why an action was refused.
• Functions hold business logic of any complexity.
• Permissions decide who can see which objects and who can run which actions.

An operational ontology adds behaviour, rules and permissions to the description, and that brings it very close to a DDD model. The names differ, but the ideas match closely:

Palantir Ontology	Closest idea in DDD
Object type	Entity
Link type	Relationship between entities or aggregates
Action type	A command, like order.cancel()
Submission criteria	Invariants and checks before a command runs
Function	Domain service

These are close relatives, not exact matches. An action type, for example, can change several objects at once, while DDD prefers one aggregate per change. Still, a DDD developer who reads Palantir's documentation will recognise most of it. The new part is mostly who uses the model.

Why AI agents need a domain model

An AI agent is a program built on a large language model (LLM, the kind of AI behind chat assistants) that does tasks by calling tools: it reads data, decides what to do and acts. To act on a business, an agent needs to know what exists, how things connect and what it may change. A database schema (the list of tables and their columns) is a poor source for that:

• Table and column names don't explain themselves. ord_hdr.st_cd = 4 means nothing to an agent, or to a new developer.
• The rules aren't in the tables. "A shipped order cannot be cancelled" lives in application code. An agent that writes to the database directly skips it.
• Permissions are too broad. A database login can usually change any row. The business wants rules like "support staff can cancel orders, but only before shipping".

An ontology gives an agent the domain model without the database: business names, links it can follow, and a short list of actions whose rules are checked for it. Palantir's AI chatbots, for example, get tools that query objects, follow links and run actions, and each action can run automatically or only after a user confirms it.

A semantic interface is a layer that offers the domain in business words: named things, the links between them and the actions allowed on them. The diagram shows where it sits. The agent never talks to the database; every change goes through the domain model, which checks the rules.

⤢ enlarge

This is not only a Palantir idea. The Model Context Protocol (MCP), an open standard for connecting AI applications to outside tools, works the same way. A server describes each tool with a name, a description and the inputs it accepts. The specification also says the server must validate every input and control who may use each tool, and that a person should be able to refuse a tool call.

Where to start if you already know DDD

If you already know DDD, don't start by learning ontology tools: start by exposing the domain model you already have. The question to ask is: how can my existing domain model become an interface that both applications and AI agents can understand and use safely?

These steps turn a DDD model into that interface:

1. List the commands of each aggregate. A command is a method that changes the aggregate, like cancel(). Each command (cancel an order, refund a payment) becomes one action an agent can call. Expose nothing else that changes data.
2. Describe every action in the ubiquitous language. The description is what the agent reads to decide what to do, so say what the action does and when it is refused.
3. Expose reads as queries that follow relationships. "Orders of this customer" and "payment of this order" use the same links the ontology diagram shows.
4. Keep the rules in the domain model. Never rely on the prompt to enforce an invariant. The agent may ignore a prompt; it cannot get around cancel().
5. Check permissions for each action. Decide who may run each action, and make the agent act as a specific user, not as an account that can do everything.
6. Ask for confirmation on risky actions. Refunds, deletions and anything else that is hard to undo should wait for a person to approve it.

Here is the order aggregate from earlier, exposed as a tool in the shape MCP uses. orders is the application's repository (the class that loads and saves orders) and user is the person the agent acts for. Both, and the User type, come from the existing application; they are not defined here.

const cancelOrderTool = {
  name: 'cancel_order',
  description:
    'Cancel a customer order. An order that has already shipped cannot be cancelled.',
  inputSchema: {
    type: 'object',
    properties: {
      orderId: { type: 'string', description: 'The ID of the order to cancel' },
    },
    required: ['orderId'],
  },
};

async function handleCancelOrder(args: { orderId: string }, user: User) {
  const order = await orders.findById(args.orderId);
  if (!order) {
    return { isError: true, content: [{ type: 'text', text: `No order ${args.orderId}.` }] };
  }
  if (!user.can('cancel', order)) {
    return { isError: true, content: [{ type: 'text', text: 'You may not cancel this order.' }] };
  }

  try {
    order.cancel(); // The invariant lives in the domain model, not in the prompt.
  } catch (error) {
    return { isError: true, content: [{ type: 'text', text: (error as Error).message }] };
  }

  await orders.save(order);
  return { content: [{ type: 'text', text: `Order ${args.orderId} is cancelled.` }] };
}

The tool adds almost nothing new. The name and description come from the ubiquitous language, the permission check comes from the application, and the rule comes from the aggregate. The domain model was already the hard part, and it was already done.

What to take away

Ontologies and DDD describe a business the same way: in its own words, as things and the links between them. A classic ontology stops at the description, so many systems can share it. DDD goes further and puts the rules in code that refuses to break them. Operational ontologies, like Palantir's, add actions, rules and permissions, which brings them very close to DDD.

What is new is the user. AI agents need a model of the business that they can read and act on without knowing how the database works. For a team that already practises DDD, most of that model exists. The work is to expose it as a set of clear queries and safe actions, and the rules that protect it are already in place.