DDD Boundaries Review

Use this skill when the main problem is not syntax or style, but unclear domain boundaries.

Core principle: Fix context leakage before adding more patterns.

Quick Reference

HARD-GATE

DO NOT recommend splitting code into new contexts unless the business boundary is explicit enough to name.
DO NOT treat every large module as a bounded context automatically.
ALWAYS identify the leaked language or ownership conflict before proposing structural changes.

When to Use

• The repo appears to mix multiple business concepts under one model or service namespace.
• Teams are debating ownership, boundaries, or where a rule belongs.
• A Rails architecture review reveals cross-domain coupling.
• Next step: Chain to ddd-rails-modeling when a context is clear enough to model tactically, or to refactor-safely when boundaries need incremental extraction.

Review Order

1. Map entry points: Start from controllers, jobs, services, APIs, and UI flows that expose business behavior.
2. Name the contexts: Group flows and rules by business capability, not by current folder names alone.
3. Find leakage: Look for terms, validations, workflows, or side effects crossing context boundaries.
4. Check ownership: Decide which context should own invariants, transitions, and external side effects.
5. Propose the smallest credible improvement: Rename, extract, isolate, or wrap before attempting large reorganizations.

Output Style

Write findings first.

For each finding include:

• Severity
• Contexts involved
• Leaked term / ownership conflict
• Why the current boundary is risky
• Smallest credible improvement

Then list open questions and recommended next skills.

Detecting Leakage

Use ripgrep to find cross-context references before reading code manually:

# Find references from one context into another
rg 'Billing.*Fleet|Fleet.*Billing' app/

# Find cross-namespace constant usage
rg 'Billing::[A-Z]' app/services/fleet/
rg 'Fleet::[A-Z]' app/services/billing/

# Find callbacks that touch foreign concepts
rg 'after_(create|update|save).*Job|after_(create|update|save).*Mailer' app/models/

See EXAMPLES.md for a worked leakage example, a sample finding block, and pitfalls.

Integration