ddd

Apply Domain-Driven Design patterns to organize codebases by domain, layer, and policy.

2|Updated Apr 7, 2026
One-click install
npx skills add https://github.com/soumyaray/ray-ai-skills --skill ddd-soumyaray
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: ddd
Source: https://github.com/soumyaray/ray-ai-skills/tree/main/ray-ddd
Command: npx skills add https://github.com/soumyaray/ray-ai-skills --skill ddd-soumyaray

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Complex domain logic and architectural boundaries can become hard to maintain as software scales. This Skill provides a cohesive blueprint for applying Domain-Driven Design (DDD) patterns and conventions to structure codebases, align teams, and reduce coupling between domain, application, and infrastructure.

Core Features & Use Cases

  • Clear layering guidance for domain, infrastructure, application, and presentation boundaries.
  • Guidance on Entities vs Value Objects, Aggregates, and repository interactions to preserve domain integrity.
  • Patterns for services, policies, and gateway/mapper interactions to support end-to-end workflows.

Quick Start

Study the DDD guidelines and begin structuring your project according to domain, layer, and policy rules.

Frequently Asked Questions about ddd

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I enforce Domain-Driven Design architecture patterns in my codebase?

You can enforce Domain-Driven Design architecture patterns by applying standardized guidance for domain entities, value objects, aggregates, repositories, and gateway/mapper interactions to establish clean codebase layering. This provides cohesive blueprints separating domain, application, and infrastructure boundaries.

What is the difference between entities and value objects in domain modeling?

In domain modeling, the distinction between entities and value objects preserves domain integrity within aggregates. Entities maintain identity over time, while value objects are immutable descriptors, ensuring clear architectural boundaries and reducing coupling across domain layers.

When do I need DDD layering for domain, application, and infrastructure boundaries?

You need DDD layering when complex domain logic and architectural boundaries become hard to maintain as software scales. Separating domain, application, infrastructure, and presentation boundaries reduces coupling and aligns teams on clean structural conventions.

What's the best way to separate domain policies from infrastructure services?

The best way to separate domain policies from infrastructure services is by applying dedicated patterns for services, policies, and gateway/mapper interactions. This separation supports end-to-end workflows while maintaining strict architectural boundaries between layers.

Does this DDD architecture guidance work for projects with existing repository patterns?

Yes, this DDD architecture guidance works for projects with existing repository patterns by defining standardized interactions between repositories, aggregates, and domain entities. It structures existing codebases without requiring complete rewrites, preserving domain integrity.

Why does domain logic become coupled without DDD architecture conventions?

Domain logic becomes coupled without DDD architecture conventions because complex domain logic and architectural boundaries degrade as software scales. Applying Domain-Driven Design patterns and conventions structures codebases to reduce coupling between domain, application, and infrastructure layers.