Enterprise DDD Architecture
Use this skill for large systems where domain boundaries, ownership, and cross-team scaling matter more than local feature speed.
Use This Skill When
- Multiple domains must be isolated (billing, auth, catalog, attendance, etc.).
- You need explicit module contracts across frontend and backend.
- Event-driven integration is preferred over direct cross-module coupling.
- Monorepo governance and release boundaries are required.
Do Not Use When
- Project is small or single-team with low domain complexity.
- A simple layered architecture is sufficient.
Architecture Contract
- Model domain boundaries first (bounded contexts).
- Keep each domain module internally FSD-like and externally contract-based.
- Forbid deep cross-module imports.
- Communicate across modules/services with events or stable APIs.
- Maintain separate deployable apps and services.
- Keep shared packages infra-only (
types, ui, config, utils).
Recommended Structure
apps/ deployable apps
modules/ bounded-context frontend modules
services/ bounded-context backend services
packages/ shared infrastructure packages
infrastructure/ deployment and platform resources
Implementation Workflow
1) Domain Modeling
- List domains and ownership.
- Define each module public API (
index.ts) first. - Define event contracts and versioning.
2) Module Design (Frontend)
- Apply FSD inside a domain module:
entities, features, widgets, shared.- Export only public APIs from module root.
- Keep domain state and API hooks inside module boundary.
3) Service Design (Backend)
- Keep domain, application, infrastructure, presentation separation.
- Use repository interfaces in domain layer and implementations in infrastructure.
- Emit domain events for cross-service actions.
4) Integration Rules
- Allowed: event bus, API client boundary, declared public exports.
- Forbidden: direct imports into other module internals.
- Enforce via lint/import rules in CI.
5) Rollout
- Start with 1-2 high-value domains.
- Add generators/templates for new domain modules.
- Track coupling metrics and refactor hot paths.
Decision Matrix
- Need independent scaling per domain: choose DDD.
- Need strict module ownership across teams: choose DDD.
- Need fastest delivery on small scope: avoid DDD for now.
Output Requirements for Agent
- Propose target domain map.
- Provide import/event boundary rules.
- Provide migration plan from current structure to target structure.
- Include risks, rollback plan, and testing strategy.
References
- Detailed structures, code templates, generators, and examples:
references/guide.md
