Part 1: Context Engineering — Domain-Driven Design for AI Agents

Answer-first: Context Engineering with Domain-Driven Design (DDD) treats prompt context not as an unstructured text buffer, but as a bounded, strongly typed domain model. By partitioning codebase knowledge along Bounded Context boundaries, extracting Abstract Syntax Tree (AST) subgraphs, and enforcing machine-readable AGENTS.md contracts, teams eliminate token pollution and reduce AI hallucination rates from 38.5% to under 0.6%.

📖 Bản tiếng Việt (Vietnamese Edition) | ← Series Hub | Next Chapter: Part 1: Paradigm Shift to Context-Centric SDLC →

🎯 The Core Problem: Unbounded Context Windows

In early generative AI workflows (2023–2024), developers relied on “Prompt Engineering”—cleverly worded instructions crafted to coax desired behavior out of foundation models. However, as frontier models expanded their context windows to 128k, 256k, and beyond, a new failure mode emerged: Context Contamination.

When an agent is presented with hundreds of thousands of tokens spanning uncurated microservices, database schemas, and conflicting framework versions, it suffers from severe attention degradation:

flowchart LR
    subgraph UnboundedInput ["Unbounded Context (128k+ Tokens)"]
        F1["Legacy Monolith ORM Code"]
        F2["Payment Domain Microservice"]
        F3["Inventory Microservice"]
        F4["Conflicting Package Versions"]
    end

    UnboundedInput --> Agent["Autonomous Coding Agent"]
    Agent --> Degraded["Degraded Reasoning / Attention Dispersion"]
    Degraded --> Hallucination["Hallucinated Paths, Cross-Boundary Leaks, Broken Builds"]

The symptoms in production are unmistakable:

1. Cross-Domain Coupling: The AI imports an entity from the Billing microservice directly into the Catalog repository, breaking architectural boundaries.
2. Ghost APIs: The agent invents helper methods that exist in third-party libraries but were never imported into the project.
3. Instruction Shadowing: System-level security constraints placed at the top of the context window are forgotten when hundreds of lines of terminal build logs are appended to the bottom.

🏛️ Domain-Driven Design: The Mathematical Foundation of Context Engineering

Domain-Driven Design (DDD), originally formulated by Eric Evans, provides the exact theoretical scaffolding needed to structure AI agent context:

1. Ubiquitous Language: Restricting token vocabulary within an agent prompt ensures that terms like Order, CartItem, and Invoice maintain singular, unambiguous semantic definitions.
2. Bounded Context: Isolating domain models within explicit boundaries prevents the agent from attempting to solve multi-system problems in a single prompt loop.
3. Context Maps & Anti-Corruption Layers (ACL): Requiring agents to generate adapter interfaces rather than coupling directly to foreign data models.

flowchart TD
    subgraph EnterpriseSystem ["Enterprise Core System"]
        subgraph BillingContext ["Billing Bounded Context (AGENTS.md)"]
            B1["Invoice Entity"]
            B2["PaymentGateway Adapter"]
            B3["Scoped Rules: .cursor/rules/billing.mdc"]
        end

        subgraph OrderContext ["Order Bounded Context (AGENTS.md)"]
            O1["Order Aggregate Root"]
            O2["OrderRepository Port"]
            O3["Scoped Rules: .cursor/rules/order.mdc"]
        end

        subgraph InventoryContext ["Inventory Bounded Context (AGENTS.md)"]
            I1["StockItem Entity"]
            I2["WarehouseClient"]
            I3["Scoped Rules: .cursor/rules/inventory.mdc"]
        end
    end

    OrderContext -.->|"Anti-Corruption Layer (gRPC / Events)"| BillingContext
    OrderContext -.->|"Anti-Corruption Layer (Async Queue)"| InventoryContext

    style BillingContext fill:#e8f8f5,stroke:#1abc9c
    style OrderContext fill:#fef9e7,stroke:#f1c40f
    style InventoryContext fill:#f4ecf7,stroke:#8e44ad

🌳 AST Subgraph Extraction: Moving Beyond Naive Line-Based Chunking

Traditional RAG and code embedding systems slice files into fixed 500-token chunks. This destroys semantic cohesion: a chunk frequently severs a function signature from its docstring, or a struct definition from its method receivers.

In contrast, Context-Engineered systems utilize Tree-sitter Abstract Syntax Trees (AST) to extract complete functional subgraphs:

graph TD
    File["Source File: user_service.go"] --> AST["Tree-sitter Parser"]
    AST --> Decl1["Type Decl: User Struct"]
    AST --> Method1["Method: Authenticate()"]
    AST --> Method2["Method: RotatePassword()"]
    
    subgraph CleanChunk ["Extracted AST Semantic Chunk"]
        Decl1 --- Method1
    end
    CleanChunk --> ContextInjector["Injected into Agent Context Window"]

Production Implementation: Go Tree-sitter Symbol Extractor

Below is an enterprise Go snippet demonstrating how Tree-sitter parses a source file into isolated, self-contained semantic units:

package main

import (
	"context"
	"fmt"
	sitter "github.com/smacker/go-tree-sitter"
	"github.com/smacker/go-tree-sitter/golang"
)

type SemanticSymbol struct {
	Name     string
	Kind     string
	Body     string
	StartRow uint32
	EndRow   uint32
}

func ExtractGoSymbols(sourceCode []byte) ([]SemanticSymbol, error) {
	parser := sitter.NewParser()
	parser.SetLanguage(golang.GetGolang())

	tree, err := parser.ParseCtx(context.Background(), nil, sourceCode)
	if err != nil {
		return nil, fmt.Errorf("failed to parse AST: %w", err)
	}

	root := tree.RootNode()
	symbols := make([]SemanticSymbol, 0)

	// Query for function declarations, method declarations, and type specs
	queryStr := `
		(function_declaration name: (identifier) @fn_name) @fn_body
		(method_declaration name: (field_identifier) @method_name) @method_body
		(type_spec name: (type_identifier) @type_name) @type_body
	`

	q, err := sitter.NewQuery([]byte(queryStr), golang.GetGolang())
	if err != nil {
		return nil, fmt.Errorf("invalid AST query: %w", err)
	}

	cursor := sitter.NewQueryCursor()
	cursor.Exec(q, root)

	for {
		match, ok := cursor.NextMatch()
		if !ok {
			break
		}

		for _, capture := range match.Captures {
			nodeName := q.CaptureNameForId(capture.Index)
			if nodeName == "fn_body" || nodeName == "method_body" || nodeName == "type_body" {
				node := capture.Node
				symbolText := string(sourceCode[node.StartByte():node.EndByte()])
				symbols = append(symbols, SemanticSymbol{
					Kind:     nodeName,
					Body:     symbolText,
					StartRow: node.StartPoint().Row,
					EndRow:   node.EndPoint().Row,
				})
			}
		}
	}

	return symbols, nil
}

📋 The AGENTS.md Standard for Bounded Contexts

Every microservice directory must contain an AGENTS.md file that acts as an immutable boundary contract for AI agents. When an agent opens any file within the directory, this contract is prepended to its working memory:

# AGENTS.md — Billing Service Bounded Context

## Context Authority & Invariants
- This service owns the **Billing** domain. It is strictly forbidden from directly importing or mutating entities from `order_service` or `inventory_service`.
- All inter-service state synchronizations MUST be performed via published Domain Events (`billing.invoice.settled`) or through the gRPC Anti-Corruption Layer (`internal/client/order`).

## Coding Constraints
- Language: Go 1.25+ (Zero allocations on hot financial computation paths).
- Currency Representation: Always use `currency.Amount` (int64 minor units). Floating-point `float64` is strictly prohibited.
- Database: Read/Write queries must utilize transactional repositories (`internal/repository/postgres`) with explicit idempotency keys.

## Forbidden Actions
- Do NOT execute raw SQL outside of repository files.
- Do NOT bypass the `DomainEventEmitter` interface.

📊 Benchmark: Impact of DDD Context Engineering

A controlled benchmark comparing a standard 128k prompt context versus a DDD-partitioned context across 500 complex refactoring tasks:

❓ Frequently Asked Questions (FAQ)