deno-ddd

# Domain-Driven Design in Deno

## When to Use This Skill

Use this skill when:
- Building applications with complex business logic
- Implementing hexagonal/clean architecture in Deno
- Structuring large-scale Deno applications
- Separating domain logic from infrastructure
- Working with bounded contexts and aggregates
- Need clear separation between layers

**Prerequisites:** Always read `deno-core.md` first for essential Deno configuration.

---

## Project Philosophy

> **Clean, Modern TypeScript**: Embrace Deno's vision of secure, modern JavaScript/TypeScript development without the baggage of Node.js legacy patterns.

> **Domain-Driven Design**: Follow DDD principles with clear separation between domain logic, application services, and infrastructure concerns.

> **TypeScript-First**: Leverage TypeScript's type system for safety and developer experience. No `any` types in production code.

---

## Core DDD Principles

### Ubiquitous Language
- Use domain terminology consistently in code, docs, and conversations
- Type names, method names, and variables should match business concepts
- Avoid technical jargon in domain layer

### Bounded Contexts
- Each context has its own models and language
- Clear boundaries between contexts
- Explicit translation between contexts

### Layered Architecture
1. **Domain Layer** - Pure business logic, no dependencies
2. **Application Layer** - Use cases, orchestration
3. **Infrastructure Layer** - External services, databases, APIs
4. **API Layer** - HTTP handlers, CLI, GraphQL resolvers

---

## Project Structure

### Recommended Directory Layout

```
src/
├── domain/                    # Domain layer - core business logic
│   ├── entities/              # Domain entities (Memory, User, Order)
│   │   ├── user.ts
│   │   └── order.ts
│   ├── value-objects/         # Immutable values (Email, Money, Status)
│   │   ├── email.ts
│   │   ├── money.ts
│   │   └── order-status.ts
│   ├── aggregates/            # Consistency boundaries