application

Note: Examples use companyId as the multi-tenant identifier. Replace with your project's term (e.g., organizationId, tenantId).

Application Layer

This skill covers everything inside a bounded context's application/ directory: use cases, CQRS handlers, DTOs, ports, application services, and Redis read models.

---

1. Pattern Selection

Work through this flowchart before writing a single line of code.

Does the module already use CQRS (CommandBus / QueryBus)?
├── No  → Pattern A (plain UseCase + TOKEN)
└── Yes →
        Is this a simple read (findById) with no RBAC or transformation?
        ├── Yes → Skip use case — inject repository directly in controller
        └── No  →
                Does orchestration span multiple services (QueryBus calls,
                multiple ports, complex enrichment)?
                ├── Yes → Pattern C (Handler as Orchestrator)
                └── No  → Pattern B (CQRS Command/Query)

Need read model / projections?
└── CQRS R/W separation: write side → Pattern B/C, read side → Redis query handler
    (see references/read-model-patterns.md)

Reusable logic between 2+ handlers?
└── Extract into Application Service (@Injectable, in application/services/)

Shared domain logic (no I/O, no framework)?
└── Extract into Domain Service (plain class, in domain/services/)

---

2. Pattern A — Plain UseCase with TOKEN

Use when the context uses plain use cases without CQRS (e.g., customers, contacts).

Directory layout

application/
├── dtos/
│   └── create-<context>.dto.ts
└── usecases/
    ├── create-<context>.usecase.ts
    └── __tests__/
        └── create-<context>.usecase.spec.ts

DTO

// application/dtos/create-<context>.dto.ts
export namespace Create<Context>Dto {
  export interface Input {
    companyId: string;
    name: string;
    // add domain-specific fields
  }

  export interface Output {
    id: string;
    companyId: string;
    name: string;
    createdAt: Date;
  }
}