j5ik2o DDD Module Pattern
A DDD module should hide implementation detail and expose a small language-shaped API.
Workflow
Identify the bounded context or subdomain the module represents.
Group aggregates, value objects, domain services, policies, and events by domain concept.
Expose only stable commands, queries, ports, and domain types needed by other modules.
Keep persistence mapping and framework glue outside the domain module or behind adapters.
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.