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
- Open VS Code
- Open GitHub Copilot Chat
- Open the agents dropdown
- Select Configure Custom Agents
- 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
- Open GitHub Copilot Chat
- Open the agents dropdown
- 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.
Top comments (0)