Exploring spec-driven development with Ontologies and Domain Design Models

- 3 minutes read - 547 words

Introduction

One of the more interesting recent developments in Retrieval-Augmented Generation (RAG) is Knowledge Graph–based RAG. Unlike traditional vector-based retrieval, this approach introduces structured relationships between entities, enabling deeper reasoning and better contextual understanding.

This naturally raises a question:

Can we build more robust and reliable software systems by combining:

  • Ontologies

  • Domain-specific design models

  • Spec-driven development (SDD)

This article explores that idea through a practical comparison.

Motivation

I have always been a strong advocate of design models and industry-standard frameworks. Over the years, I’ve collected and studied several, including:

  • BIAN – Banking Industry Architecture Network

  • SCOR – Supply Chain Operations Reference

  • ACORD – Insurance domain architecture

  • TM Forum – Telecom data and process models

These models provide:

  • Standardised terminology

  • Well-defined business capabilities

  • Structured relationships between concepts

  • Proven domain abstractions

Given my current work context, I started experimenting with applying BIAN in AI-assisted development workflows.

Hypothesis

The hypothesis is simple:

If we combine knowledge graph RAG with domain design models and spec-driven development, we should be able to produce:

  • More consistent outputs

  • Better structured designs

  • Reduced ambiguity in terminology

  • Stronger alignment with real-world domains

Two Approaches Compared

To validate this idea, I experimented with two approaches:

1. Spec-Driven Development (SDD) Only

In this setup:

  • System design is driven purely by specifications

  • LLM generates outputs based on prompts and specs

  • No formal domain model or ontology is enforced

Observations:

  • Inconsistent terminology across components

  • Repeated re-interpretation of domain concepts

  • Harder to maintain alignment across iterations

  • Outputs depend heavily on prompt quality

2. Combined Approach

This approach integrates:

  • Domain design models (e.g., BIAN)

  • Ontology-driven relationships

  • Spec-driven development

Architecture conceptually looks like:

User SpecSpec-driven DevelopmentCoding AgentDomain Model (BIAN/SCOR/etc)Ontology LayerGenerated System Designinputreferrefer

Observations:

  • Much more consistent terminology

  • Outputs are well-organised and structured

  • Domain concepts are reused instead of reinvented

  • Improved traceability between requirements and design

  • Easier to scale across teams and iterations

Why the Combination Works

1. Ontologies Provide Semantic Backbone

Ontologies define:

  • Entities

  • Relationships

  • Constraints

This allows the system to “understand” meaning rather than just text similarity.

2. Domain Models Provide Proven Structure

Frameworks like BIAN or ACORD:

  • Encode years of industry knowledge

  • Define canonical business capabilities

  • Provide reusable design patterns

This reduces the need to “rediscover” architecture.

3. Ontology Enables Contextual Retrieval

Compared to vector search:

  • Relationships are explicit

  • Multi-hop reasoning becomes possible

  • Context is preserved across entities

4. Spec-Driven Development Keeps It Grounded

Specs ensure:

  • Alignment with actual requirements

  • Deterministic outputs

  • Repeatability

Key Insights

From this exploration:

The combination approach clearly produces better results than SDD alone.

Specifically:

  • Better organisation

  • More consistent terminology

  • Stronger domain alignment

  • Reduced ambiguity

This is especially important in domains like:

  • Banking (BIAN)

  • Insurance (ACORD)

  • Supply chain (SCOR)

  • Telecom (TM Forum)

Implications for AI-Native Architecture

This pattern suggests a new direction:

“Model-Augmented RAG”

Instead of:

Prompt → Coding Agent → Output

We move towards:

Prompt + Spec + Domain Model + Ontology → Coding Agent → Structured Output

This is closer to how real-world systems are designed.

Future Exploration

Some interesting directions to explore:

  • Integrating DDD aggregates and microservcies into domain specific models

  • Using ontology and domain specific models for architecture validation

  • Combining with agentic workflows for iterative refinement

Conclusion

By combining:

  • Ontologies

  • Domain design models

  • Spec-driven development

we can move closer to:

AI systems that generate not just code — but well-designed, domain-aligned software architectures.

comments powered by Disqus