DDD Domain-Driven Design TypeScript Cursor Rules Template for Cursor AI

Overview

\nThe Cursor rules configuration is a Cursor AI editor instruction profile that guides Cursor AI in generating TypeScript code for a Domain-Driven Design (DDD) backend. This Cursor rules template is tailored for a DDD stack using TypeScript, hexagonal architecture, PostgreSQL, and JWT-based authentication. It enforces domain boundaries and safe AI-assisted development while remaining paste-friendly for project roots.

\nWhen to Use These Cursor Rules

\n\n- Starting a new DDD-based TypeScript backend with Cursor AI support.
\n- Enforcing strict domain boundaries across domain, application, and infrastructure layers.
\n- Guiding AI-generated code to follow hexagonal architecture and repository patterns.
\n- Configuring authentication, data access, and testing workflows with Cursor AI.
\n- Ensuring safe, auditable AI-generated code that respects project conventions.
\n\nCopyable .cursorrules Configuration

\n.cursorrules\nFramework: TypeScript\nStack: DDD + Cursor AI\nRole & Context: You are a senior TypeScript engineer specializing in Domain-Driven Design. Build a backend with Node.js, TypeORM, PostgreSQL, and Cursor AI. Follow strict domain boundaries and hexagonal architecture.\nCodeStyle: ESLint + Prettier, 4 spaces, strict TypeScript config\nArchitecture & Directory Rules: Hexagonal architecture, module-per-domain, clear domain boundaries between domain, application, and infra. Use src/domain, src/application, src/infra, src/interfaces, tests.\nAuthentication & Security Rules: JWT-based authentication (HS256); store secrets in environment variables; never hardcode secrets.\nDatabase & ORM patterns: PostgreSQL with TypeORM; implement repository pattern; avoid raw SQL in domain; use parameterized queries.\nTesting & Linting Workflows: Vitest for unit tests; integration tests with a test database; linting on commit; type-check in CI.\nProhibited Actions & Anti-patterns: Do not access infrastructure directly from domain; do not bypass domain boundaries; do not generate unsafe SQL strings; do not rely on runtime eval.\n\nRecommended Project Structure

\nsrc/\n  domain/\n    order/\n      aggregates/\n      entities/\n      value-objects/\n  application/\n  infrastructure/\n    database/\n      migrations/\n      repositories/\n  interfaces/\n    http/\n      controllers/\n  tests/\n\nCore Engineering Principles

\n\n- Domain-first design: code and tests reflect the language of the domain model.
\n- Strong typing: leverage TypeScript to enforce domain invariants at compile time.
\n- Clear boundaries: strict separation between domain, application, and infrastructure.
\n- Testability: design aggregates and services for deterministic unit tests and integration tests.
\n- Safe AI-assisted development: Cursor AI should augment but not override domain rules.
\n- Idempotent commands: make commands idempotent and theme-runner friendly.
\n\nCode Construction Rules

\n\n- Use domain-driven patterns: aggregates, value objects, domain events, repositories.
\n- Prefer explicit interfaces over concrete types across boundaries.
\n- Value objects for identifiers and invariants; avoid primitive obsession.
\n- DTOs for application services and API adapters; keep domain models pure.
\n- Repository pattern for persistence; domain should not know about ORM internals.
\n- Dependency injection: compose services in a central container; avoid new calls in domain logic.
\n- Use TypeScript enums and discriminated unions for clarity in messages and events.
\n- Documentation in inline comments only where it adds value; rely on types for understanding.
\n\nSecurity and Production Rules

\n\n- Environment-based configuration: secrets loaded from env vars; never commit secrets.
\n- JWT-based authentication with short-lived tokens; rotate refresh tokens securely.
\n- Input validation and output encoding to prevent injection and XSS risks in APIs.
\n- Parameterize queries; avoid string concatenation for SQL to prevent SQL injection.
\n- Audit logging and error handling; avoid leaking sensitive information in errors.
\n- TLS in transit; proper CORS and rate-limiting for public APIs.
\n\nTesting Checklist

\n\n- Unit tests for domain objects and aggregates; verify invariants and edge cases.
\n- Integration tests for repositories and adapters using a test database.
\n- Contract tests for API boundaries; validate DTO transformations.
\n- End-to-end tests for critical user flows (where applicable).
\n- CI checks: type-check, lint, unit tests, and integration tests on PRs.
\n\nCommon Mistakes to Avoid

\n\n- Ignoring domain boundaries and letting infrastructure leak into domain code.
\n- Overusing anemic domain models; missing rich behavior on aggregates.
\n- Relying on ORM internals in domain or application layers.
\n- Neglecting tests for domain invariants and event flows.
\n- Hardcoding secrets or relying on unsafe code generation patterns.
\n\nFAQ

\nWhat is this Cursor rules template for DDD TypeScript?

\nA copyable Cursor rules configuration block and stack-specific guidance for building a DDD-based TypeScript backend with Cursor AI, Hexagonal Architecture, and PostgreSQL.

\nWhat stack does this template cover?

\nTypeScript backend, Domain-Driven Design, Hexagonal Architecture, PostgreSQL, TypeORM, JWT authentication, and Cursor AI guidelines for safe AI-assisted development.

\nHow do I apply the .cursorrules block?

\nCopy the entire block from the Copyable .cursorrules Configuration section and paste it into a file named .cursorrules at your project root. Cursor AI will adhere to the rules during code generation.

\nWhat should I watch out for in production?

\nKeep strict type-checking, enforce API boundaries, secure authentication flows, and ensure domain events align with the domain model. Avoid anti-patterns like God objects and database-centric domain logic.

\nWho maintains these templates?

\nSuhas Bhairav maintains Cursor Rules Templates focusing on safe AI-assisted development and practical, stack-specific guidance.