Ddd Module Pattern

DDD Module Pattern

A DDD module should hide implementation detail and expose a small language-shaped API.

Workflow

1. Identify the bounded context or subdomain the module represents.

2. Group aggregates, value objects, domain services, policies, and events by domain concept.

3. Expose only stable commands, queries, ports, and domain types needed by other modules.

4. Keep persistence mapping and framework glue outside the domain module or behind adapters.

5. Use language visibility features to enforce the boundary.

Checks

• Module names should be domain terms, not technical layers alone.

• Public APIs should be smaller than internal files.

• Cross-module calls should go through explicit interfaces or application services.

• Shared kernels must stay small and stable.

Reference

Read references/language-guides.md for language-specific visibility and package patterns.

Detailed Reference

For non-trivial implementation, review, or refactoring work, read references/details.md before giving final guidance. It contains the detailed rules, examples, smells, and migration notes that do not belong in the short invocation body.

Output

Return a proposed module tree, public API, hidden internals, and dependency direction.