DDD Foundations Skill

The layering map and term definitions for any DDD bounded context, in any language. Every other DDD skill in this set references the four layers and the canonical names below. Packages, modules, namespaces, and directories are all "modules" here — use whatever your language provides to make the boundaries real.

Foundational principle. Domain depends on nothing in your code — only the language's standard library and your own domain types. Infrastructure and api depend inward. The word "service" without a qualifier is meaningless: say application service (use-case orchestration, owns the transaction, returns DTOs) or domain service (stateless domain logic that doesn't naturally belong to one aggregate), and put each in the layer named after it. The layers are enforced by module boundaries and architecture tests — violations show up as imports, not as code review findings.

Red Flags — STOP if you find yourself thinking:

• "Repository = persistence = infrastructure, so the interface goes there too."
• "It feels tidy to put the interface next to its implementation."
• "It's just a service — service/ is fine for both kinds."
• "We're a small team / it's a small BC, let's keep it flat in one module and split later."
• About to import a persistence framework (ORM, query builder) or HTTP framework (router, request/response types) inside a type under <bc>/domain.
• About to import anything from <bc>/infrastructure in a type under <bc>/domain or <bc>/application.
• About to name a new class FooService without Application or Domain in the name.

If any of these surface, re-read Core Rules and Excuse / Reality before typing.