From DDD to Ontology: Turning Domain Knowledge into AI‑Ready Semantic Contracts

Why Agents Need Semantic Assets

Agents that participate in enterprise decision‑making must answer questions beyond locating data: who is the customer, what is the current status, when should intervention occur, which actions are possible, and on what basis those actions are taken. Raw data records events but cannot alone provide reliable business understanding. A layer of semantic assets enables humans and Agents to share the same business concepts, judgment rules, and action boundaries. Ontology organizes scattered data, rules, and capabilities into a computable, executable business semantics.

From DDD to Ontology – What Is Missing

Domain‑Driven Design (DDD) models serve a bounded context and are developer‑centric; the consumer is the programmer and the product is runnable code. An Agent, however, needs cross‑context knowledge. Using the customer‑health‑score scenario, the Agent must know:

Cross‑system identity : Do the three IDs in CRM, ticketing, and finance refer to the same company?

Metric definition : Which dimensions, weights, and time windows compose the Health Score?

Rule version : What conditions trigger an alert, who maintains the rule, and which version is active?

Judgment evidence : Which data and rules support the conclusion and how trustworthy are they?

Action boundaries : Which actions are currently permitted, who can execute them, and is approval required?

DDD does not forbid these concerns; in practice they are scattered across data warehouses, gateways, documentation, and code. Developers can piece them together, but an Agent needs a stable, queryable context.

Moving from DDD to Ontology involves three extensions:

Reuse existing domain assets : Extract entities, value objects, domain rules, and application services.

Bridge different contexts : Add identity mappings, attribute source definitions, and semantic relationships.

Complete runtime semantics : Unify metric definitions, rule versions, action permissions, and evidence chains.

Core Ontology Model: Fact · Logic · Action

The enterprise semantics are divided into three runnable asset types.

Fact – Object, Property, Link, State. Answers “What is the current state of the business world?”

Logic – Metric, Rule, Policy. Answers “How to compute, judge, and constrain?”

Action – Action Contract, Evidence. Answers “What can be done, how to execute, and how to trace?”

In the customer‑health‑score scenario:

Fact Layer maps the three IDs (CRM, ticketing, finance) to a single Customer object and surfaces attributes such as opportunity stage, contract expiry, recent login count, and ticket count.

Logic Layer defines the Health Score formula (weighted sum of login recency, renewal intent, and ticket satisfaction). When the score falls below 60 and the contract expires within 90 days, a churn‑risk alert is triggered. Metric definitions, thresholds, and applicable conditions are version‑controlled. Policies describe role‑based data access and approval requirements.

Action Layer wraps underlying APIs into constrained business actions. For example, “create CSM follow‑up task” can be executed automatically, “upgrade service level” requires manager approval, and “issue renewal coupon” must pass a budget check. Action contracts reference Logic‑layer policies and record caller identity, verification results, and execution evidence.

Six‑Step Construction: From Assets to a Running Semantic Service

Step 1 – Identify a High‑Value Scenario

Choose a scenario with clear value, frequent usage, and verifiable impact. Example: a B2B company with an annual churn rate of ~15% (each lost mid‑size customer costs tens of thousands of ARR). The Customer Success team (8 people) manages >4,000 active customers, and manual churn detection is too slow.

Scenario: Agent automatically identifies high‑risk churn customers and triggers follow‑up. The team enumerates involved objects, metrics, rules, and actions.

Customer unified identity – separate IDs in CRM, operations, and finance prevent confirmation of the same customer.

Health Score – manually calculated in Excel, unreadable by the Agent.

Churn alert rule – stored in analysts' heads, no versioning or audit.

Follow‑up action – created manually by sales, not triggerable by the Agent.

Output: an “Ontology Gap List” that defines construction scope and information sources.

Step 2 – Inventory Existing Assets

Existing DDD domain model – reuse entity and rule definitions.

Existing data warehouse and metric platform – start from the Metrics Layer to unify metric definitions.

If neither is complete – extract candidate definitions from business documents and interview notes (optionally with AI assistance), then have domain experts validate.

Case study: CRM defines Customer, Contract, and Opportunity; the data warehouse holds basic usage logs; the ticketing system is not integrated; the health score resides in an Excel sheet. Strategy: start from the CRM model, bridge ticketing and product behavior data, and structure the Excel calculations.

Step 3 – Consolidate Fact Assets

Extract core business objects, create identity mappings, and define relationships so that the Agent can resolve a customer across systems.

CRM Customer ─┐
运营主体 ─┼── Customer Object （统一客户身份）
客服账号 ─┘
 ├── 身份规则：统一社会信用代码 > 企业名称+地址 > 人工确认
 ├── 属性来源：
 │   商机阶段 ← CRM（权威源）
 │   信用额度 ← 财务系统（权威源）
 │   服务等级 ← 客服系统（权威源）
 │   最近登录 ← 产品日志（T+1 更新）
 │   工单满意度 ← 客服系统（实时）
 ├── 关系图：Customer → Contract (1:N) → Subscription (1:N)
 │             Customer → Case (1:N)
 │             Customer → CSM (N:1，指定客户成功经理)
 └── 置信度：高/中/低 → 低置信度进入待确认队列

Identity mapping is hierarchical: first use the unified social credit code, then name + address, and finally fall back to manual review. Governance includes an Owner for each object, versioned identity‑mapping rules, and daily conflict‑rate monitoring.

Step 4 – Consolidate Logic Assets

Transform scattered scripts, code branches, operational docs, and tacit knowledge into structured, testable, version‑controlled semantic assets.

Metric: customer_health_score
├── Formula: 100 × (login_recency × 0.3 + renewal_intent × 0.4 + ticket_satisfaction × 0.3)
├── Range: 0–100 (components normalized to 0–1)
├── Components:
│   ├── login_recency: recent 30‑day login days / 30
│   ├── renewal_intent: renewal_communication_score × 0.5 + usage_trend × 0.3 + business_response_score × 0.2
│   └── ticket_satisfaction: average CSAT of tickets in last 90 days / 5
├── Dimensions: by customer, by time (rolling daily)
├── Data sources: Login Service + CRM + Ticket System
├── Owner: Customer Success team
├── Reviewer: Data team (ensures definition consistency)
└── Version: v1.2 (effective 2026‑06‑15)

Rule: churn_risk_alert
├── Condition: health_score < 60 AND 0 ≤ contract_remaining_days ≤ 90
├── Exclusion: existing follow‑up task OR customer already confirmed renewal
├── Output: high‑risk flag + create_followup_task candidate action
├── Test set: 12 boundary cases (including exactly 60 points, exactly 90 days, etc.)
└── Version: v2.0 (adds contract‑expiry condition to reduce false positives)

Logic assets consist of:

Metric : complete formula, dimensions, data sources, and refresh frequency for Agent and BI consumption.

Rule : managed through a “define‑test‑publish‑monitor‑retire” lifecycle, preserving test cases and version history.

Policy : describes roles, data scope, risk levels, and approval requirements, shared by object queries and action execution.

Governance: metric owners confirm definitions; rule changes require approval and retain history; key metrics are periodically reconciled with business teams.

Step 5 – Consolidate Action Assets

Wrap existing APIs and application services into constrained action contracts that specify preconditions, authorizations, side effects, idempotency, and evidence requirements.

Action: create_followup_task
├── Precondition: churn_risk_alert rule hit
├── Authorization: Customer Success manager or delegated Agent; medium risk – no per‑instance approval
├── Side effect: create Task in CRM, notify assigned CSM
├── Idempotency: do not create duplicate tasks within 7 days for the same customer
└── Evidence: bind health_score snapshot + rule version + trigger time

Action: upgrade_service_level
├── Precondition: ARR > 500k AND contract_remaining_days > 180
├── Authorization: high risk – requires manager approval
├── Approval timeout: auto‑remind after 48 h, auto‑close after 7 days without response
└── Evidence: bind approval record + contract snapshot + health_score trend

Action: issue_renewal_coupon
├── Precondition: churn_risk_alert hit AND customer has no outstanding debt
├── Authorization: amount ≤ 5% of contract value AND budget available
├── Budget check: call finance system to confirm monthly coupon budget balance
└── Evidence: bind budget check result + rule version

Each decision records three evidence types:

Data evidence : source and snapshot timestamp.

Rule evidence : rule version and hit condition.

Execution evidence : triggerer, policy check result, and approval process.

Governance: action contracts follow a release process; evidence chain integrity is periodically audited.

Step 6 – Package as a Semantic Service

Load the assets into a runtime service that offers a unified API for Agents, workflows, business applications, and BI. The service returns object data, computed results, rule hits, permissible actions, and evidence references.

{
  "customer_id": "C-10042",
  "snapshot_time": "2026-07-03T10:00:00+08:00",
  "fact": {
    "name": "星辰科技有限公司",
    "contract_remaining_days": 75,
    "last_login": "2026-06-20",
    "open_cases": 3,
    "csm": "小明（客户成功经理）"
  },
  "logic": {
    "health_score": 48,
    "score_breakdown": {
      "login_recency": 0.23,
      "renewal_intent": 0.50,
      "ticket_satisfaction": 0.70
    },
    "metric_version": "health-score-v1.2",
    "rule_hit": "churn_risk_alert-v2.0",
    "risk_factors": ["30天仅登录7天", "合同75天后到期", "近60天无续费沟通记录"]
  },
  "permitted_actions": ["create_followup_task", "issue_renewal_coupon"],
  "restricted_actions": [{
    "action": "upgrade_service_level",
    "reason": "合同剩余不足 180 天，且该动作需要主管审批"
  }],
  "evidence_ref": "evidence-C10042-20260703"
}

This response gives the Agent all context needed: Fact identifies the customer, Logic explains the risk calculation, Action lists what can be done now, and Evidence provides traceability.

Agent Consumption Flow

Understand the object – Fact tells the Agent who the customer is, related contracts, tickets, and the assigned CSM.

Understand the logic – Logic reveals how the Health Score is computed, component scores, and why the churn rule fired.

Decide the action – Action shows currently allowed actions (e.g., create follow‑up task) and which actions are blocked or need approval.

Leave evidence – Each step binds data snapshots and rule versions so humans can audit the Agent’s decision.

The Adapter layer handles system differences; the Agent orchestrates tasks via the Semantic Service.

Construction Paths: Combination Over Choice

Formal Ontology (OWL+RDF) – Precise, inferable. Strong coverage of Fact, partial Logic, minimal Action.

Knowledge Graph – Strong relationship discovery. Covers Fact well, limited Logic and Action.

Data‑driven (Schema‑First) – Fast start, metric unification. Partial coverage of Fact and Logic, minimal Action.

Domain‑driven (DDD→Ontology) – Reuse existing assets. Strong Fact coverage, partial Logic and Action.

Platform‑embedded (e.g., Palantir) – Integrated, runnable. Strong coverage of all three layers.

AI‑assisted (LLM extraction) – Quick cold start from unstructured text. Partial Fact and Logic, minimal Action.

These approaches are not mutually exclusive; a practical solution often combines them: use domain models and knowledge graphs for objects, a data platform for unified metrics, a rule engine for judgments, and existing APIs for actions. LLMs can help extract candidate definitions but cannot replace expert validation.

Boundary: Ontology vs. Data‑Center Platform

Main objects : Data platforms manage datasets, data models, and metrics; Ontology manages business objects, relationships, rules, policies, and actions.

Primary consumers : Data platforms serve analysts, BI, and data applications; Ontology serves Agents, workflows, business apps, and BI.

Common interfaces : Data platforms expose SQL and data service APIs; Ontology provides a Semantic API, Resource, and Tool interfaces.

Key capabilities : Data platforms focus on integration, processing, quality, and metric consistency; Ontology adds semantic consistency, runtime judgment, controlled execution, and traceability.

Typical outputs : Data platforms produce thematic data, metric services, and reports; Ontology produces semantic contracts, action contracts, and evidence chains.

Data platforms provide reliable data and metrics, which are essential foundations for Ontology. Ontology adds business meaning, judgment, and actionable layers on top of that foundation.

Deliverables

Fact Asset : Unified object model, relationship graph, ID‑mapping rules (structured, version‑controlled).

Logic Asset : Metric definition library, rule library, policy library (executable at runtime).

Action Asset : Action contract library, evidence‑chain specification (constrained callable contracts).

Semantic Service : Query · Compute · Execute · Audit service + Adapter (API / MCP Resource / MCP Tool).

Governance Asset : Contract test suites, rule regression tests, health dashboards (continuously evolving operational system).

Conclusion

Microservices decompose systems into independently deployable units, and DDD manages complex business within bounded contexts. When an Agent becomes a consumer, additional cross‑context concerns—identity, metric definition, authorization, and evidence—must be addressed. Transitioning from DDD to Ontology reuses existing entities, rules, and metrics, then connects them into a cross‑system, queryable, executable semantic contract.

The overall path consists of three pillars:

Layered sedimentation : Fact unifies objects and relationships; Logic unifies metrics, rules, and policies; Action unifies executable capabilities and evidence.

Scenario‑driven development : Start from a high‑value, verifiable scenario, inventory assets, model facts, logic, and actions, then package them as a Semantic Service.

Service‑oriented delivery : Expose the semantics via a runtime API that agents, applications, workflows, and BI can query, compute, execute, and audit.

As more Agents integrate with enterprise systems, the reusable core must extend beyond tables and APIs to include underlying business meaning, judgment rules, and action boundaries. Ontology is the engineering carrier for that shared capability.