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

One of the most disastrous mistakes engineers make when transitioning to AI IDEs (like Cursor or Copilot) is the mindset: “Just throw the entire source code at it, the AI will figure it out.”

In small student projects (monoliths), this might work. But in an Enterprise environment, where systems are split into dozens of Microservices with millions of lines of code, recklessly “stuffing” Context leads to 3 fatal consequences:

1. Hallucination Paths: The AI invents a config.yaml file or reports a missing Dockerfile even though it clearly exists in the root directory.
2. Context Contamination: A developer is coding in the Inventory service, but the AI automatically imports the PaymentValidator class from the Billing service.
3. Token Bankruptcy: Pumping 200,000 tokens (equivalent to the entire codebase) for a simple CSS fix costs about $0.60 per request. A 10-person team can burn thousands of API dollars a month simply due to wasted context.

This article redefines how you communicate with AI through Context Engineering, built upon the architectural foundation of Domain-Driven Design (DDD).

1. The Tech Lead Perspective: Escaping the “Tool-Centric” Trap

Before diving into the technical details, we must clarify: Context Engineering is tool-agnostic. Many Tech Leads currently fall into the anti-pattern of tying their team to a single IDE (like Cursor), forgetting that the AI market shifts every week.

From an architectural standpoint, evaluate tools through the lens of Context Management:

💡 Pro Tip: Establish communication standards with AI (like .cursorrules or .clinerules) so that even if the company switches from Cursor to Windsurf tomorrow, the context architecture remains intact.

2. The Root of the Disaster: The Global .cursorrules

Most online tutorials advise creating a massive .cursorrules file at the root of the project. This is the worst Anti-pattern in a Microservices architecture.

[Production Failure Case Study]: Payment Flow Collapse due to Context Contamination An e-commerce team shared a single .cursorrules file at the Root directory for 15 microservices. A developer asked the AI to write a cancelOrder() function for the Order service. The AI read the global rules, saw the directive “Always emit a Kafka event on state change”, but accidentally called the Kafka topic for the Payment service (since this topic was also in the context it just read). Result: The order was canceled, but customer funds were stuck due to state drift between the two systems. 📊 Impact Metrics: Required manual reconciliation for 1,200 failed orders over 3 days. 📈 Before/After (Post DDD Context Implementation):

• Before: AI hallucination rate across microservice contexts was ~22%. Average time to debug context errors was 4 hours/bug.
• After: Context contamination dropped to 0%. First-shot accuracy for code generation skyrocketed to 94%.

📊 Performance Metrics (Context Engineering Results):

• Hallucination Rate: 40% → 0.8% (98% reduction)
• Token Usage: 200K → 15K per request (92.5% savings)
• API Cost: $0.60 → $0.045 per request (92.5% savings)

To fix this, we must shift to a hierarchical context loading architecture.

3. Context Loading Hierarchy

Instead of throwing everything into a “hotpot”, Context in the Enterprise must be loaded in layers, exactly replicating human cognitive processes.

Imagine a newly hired Junior Dev. You wouldn’t hand them the entire 1,000-page System Architecture document on day one. You would give them:

1. Global Rules (Company Level): “We use TypeScript and do not push straight to main.”
2. Domain Rules (Team Level): “The Payment team uses Stripe API.”
3. Task Rules (Feature Level): “Here is the Jira ticket for the refund function.”

AI needs the exact same structure. We map this using Domain-Driven Design (DDD).

3.1. Layer 1: Global Bounded Context

Create a .cursorrules file at the Root, but keep it under 50 lines. It should only contain non-negotiable compliance rules.

# Root /.cursorrules
- Ngôn ngữ chính: TypeScript, Node.js v20.
- KHÔNG BAO GIỜ được gửi raw SQL queries. Luôn dùng Prisma ORM.
- Format code theo chuẩn Prettier hiện tại.
- Khi viết Test, luôn mock external APIs.

3.2. Layer 2: Domain Bounded Context

In each Microservice folder, create a .cursorrules file specific to that Domain. Cursor and Windsurf are smart enough to prioritize local rules over global rules when you are coding inside a specific folder.

# /services/billing/.cursorrules
- Domain: Billing & Subscriptions.
- Tech stack: NestJS, PostgreSQL.
- Business Rule: Luôn làm tròn số thập phân đến 2 chữ số (dùng thư viện decimal.js).
- Kafka Topics Allowed: `billing.invoice.created`, `billing.payment.failed`.
- TUYỆT ĐỐI KHÔNG query chéo sang Database của service `Inventory`.

Result: The AI is now effectively “sandboxed” within the Billing domain. It cannot hallucinate code from the Inventory service.

4. Architectural Rules: Forcing AI into the “Skeleton-First” Mold

Even with domain isolation, AI can still write “Spaghetti Code” if left unguided. To force the AI to write Enterprise-grade code, you must impose Architectural Constraints directly in the prompt or rules.

The “Skeleton-First” Prompting Technique: Before asking the AI to write logic, command it to write Interfaces and file structures first.

“I need to build the Export Report feature. Do not write the implementation yet. Write the TypeScript Interfaces, abstract classes, and the required folder structure (Controller, Service, Repository) first for my review.”

Once the Tech Lead reviews the “Skeleton” and ensures it complies with SOLID principles, only then do you instruct the AI to fill in the code body (Implementation).

💰 Token Efficiency (Cost Numbers): The Skeleton-First method prevents the AI from generating 300 lines of flawed logic if the initial design is wrong. On average, you save about 15,000 tokens (approx. ~$0.05) per mistake iteration, while guaranteeing impeccable Design Quality.

6. Troubleshooting: Diagnosing “Context Issues”

When the AI IDE (like Cursor) ignores your rules, check the following:

🛠️ Troubleshooting: IDE Ignoring .cursorrules

• Symptom: AI generates files in weird directories, forgets naming conventions (e.g., using CamelCase instead of snake_case as defined).
• Root Cause:
  1. Rule Overflow (Context Limit): .cursorrules exceeds 300 lines, causing the AI to suffer from “Lost in the Middle” syndrome.
  2. Rule Conflicts: The .cursorrules at the Root contradicts the .cursorrules in the subfolder.
• Actionable Solution:
  1. Use Ctrl/Cmd + L and explicitly state: “Please strictly follow the local .cursorrules in this directory”.
  2. Isolate Rules: Move UI/UX rules to the /frontend/ directory and DB rules to /backend/.

Conclusion

In the world of AI-Native Engineering, the strongest developer is not the one typing the longest prompt. The strongest is the one who orchestrates the Context Window with discipline.

By splitting .cursorrules according to Bounded Contexts (DDD) and forcing AI to respect static folder structures, you eliminate 90% of the system’s silly errors (hallucinations).

However, no matter how well you optimize context locally, letting every Dev directly hit the OpenAI API from their IDE poses severe risks of source code leakage and runaway costs.

In Part 2, we will defuse this ticking time bomb by building a Private AI Ecosystem (AI Gateway via LiteLLM) — a mandatory step to control your infrastructure and escape the SaaS “Pay-per-seat” trap.