Create a Domain Driven Design custom agent for GitHub Copilot

This tutorial shows how you create and use a reusable GitHub Copilot custom agent focused on Domain Driven Design for .NET.

You end with one small agent file.

You reuse the agent across repositories.

You guide Copilot toward clean DDD decisions.

Why use a DDD custom agent

Copilot follows context.

Without guidance, design quality drifts.

A custom agent gives Copilot a stable role:

• Enforces DDD boundaries


• Protects domain purity


• Pushes behavior driven models


• Promotes test first thinking

You stop repeating architectural rules.

You focus on business problems.

Prerequisites

• Visual Studio Code 1.106 or newer


• GitHub Copilot enabled


• GitHub Copilot Chat enabled

Custom agents ship with recent VS Code releases.

What this agent enforces

The agent acts as a DDD expert for .NET projects.

Core principles:

• Clear bounded contexts


• Ubiquitous language aligned with code


• Pure Domain layer


• Explicit Application layer orchestration


• Infrastructure isolated behind ports


• Strong domain and integration tests

Step 1: Create a custom agent

1. Open VS Code


2. Open GitHub Copilot Chat


3. Open the agents dropdown


4. Select Configure Custom Agents


5. Select Create new custom agent

You now choose a location.

Location options

User profile

• Reuse across all repositories


• Best choice for personal workflows

Workspace

• Stored inside repository


• Best choice for team sharing

For team usage, select workspace.

Step 2: Add the agent file to the repository

Create this folder if missing:

.github/agents

Create a file:

ddd.agent.md

Step 3: Paste the DDD agent definition

---

name: DDD

description: Domain-Driven Design (DDD) expert for .NET

tools: ['edit', 'runNotebooks', 'search', 'new', 'runCommands', 'runTasks', 'microsoft.docs.mcp/*', 'usages', 'vscodeAPI', 'problems', 'changes', 'testFailure', 'openSimpleBrowser', 'fetch', 'githubRepo', 'extensions', 'todos', 'runSubagent', 'runTests']

---

You are a Domain-Driven Design expert for .NET (C#). Optimize for correctness and maintainability.



Non-negotiables

- Identify bounded context and ubiquitous language from the repo. Ask if unclear.

- Keep Domain pure. No infrastructure, UI, transport, persistence, logging, or framework dependencies in Domain code.

- Model behavior first. Entities (identity), Value Objects (immutable), Aggregates (consistency boundary), Domain Events (facts).

- Only the aggregate root is referenced from outside. Only mutate aggregate state via root methods which enforce invariants.

- Define application use cases in an Application layer. Orchestrate workflows, authorization, transactions, and coordination there.

- Define ports as interfaces near the Domain or Application boundary. Implement adapters in an Infrastructure layer.

- Persistence concerns live outside Domain. Use mapping or configuration code in Infrastructure to keep Domain persistence-ignorant.

- Testing: domain unit tests for invariants and behaviors, integration tests for adapters and persistence mappings, run tests after edits.



Workflow

1) Read relevant code and constraints.

2) Propose a short plan.

3) Implement with smallest safe change-set.

4) Add or update tests.

5) Run tests and fix failures.



Response format

- Questions or Assumptions

- Plan

- Changed files

- Tests to run

- Notes or Risks

Save the file.

Commit the file if using a shared repository.

Step 4: Activate the agent

1. Open GitHub Copilot Chat


2. Open the agents dropdown


3. Select DDD
   

Copilot now operates under strict DDD rules.

Step 5: Work with the agent

Write requests in domain language.

Avoid technical framing in prompts.

Example 1: Aggregate design

Introduce an Order aggregate.

Move invariants into named methods.

Add domain unit tests.

Expected outcome:

• Aggregate root creation


• Invariants enforced inside methods


• Tests validating business rules

Example 2: Bounded context split

Identify bounded contexts for Billing and Shipping.

Propose folder structure.

Hide cross context calls behind ports.

Expected outcome:

• Context boundaries


• Clear namespaces


• Explicit interfaces between contexts

Example 3: Domain events

Add OrderSubmitted domain event.

Raise event from aggregate root.

Add application handler and tests.

Expected outcome:

• Event raised inside domain logic


• Handler placed in application layer


• Tests covering behavior

What changes after adoption

• Less anemic models


• Fewer leaking dependencies


• Smaller pull requests


• Cleaner tests


• Faster design reviews

Copilot stops guessing architecture.

Copilot follows rules.

Recommended usage pattern

• Select DDD agent before architectural changes


• Switch back to default agent for trivial edits


• Keep agent file stable


• Review changes through DDD lens

Next improvements

Optional follow ups:

• Separate agent for persistence adapters


• Separate agent for testing strategy


• Team wide instruction file for baseline rules

The DDD agent stays small.

The impact stays large.