ddd-boundaries-review

Original：🇺🇸 English

Translated

Use when reviewing a Ruby on Rails app for Domain-Driven Design boundaries, bounded contexts, language leakage, cross-context orchestration, or unclear ownership. Covers context mapping, leakage detection, and smallest credible boundary improvements.

1installs

Sourceigmarin/rails-agent-skills

Added on2026-03-29

NPX Install

npx skill4agent add igmarin/rails-agent-skills ddd-boundaries-review

SKILL.md Content

View Translation Comparison →

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

Area	What to check
Bounded contexts	Distinct language, rules, and ownership
Context leakage	One area reaching across another's concepts casually
Shared models	Same object name used with conflicting meanings
Orchestration	Use cases coordinating multiple contexts without a clear owner
Ownership	Who owns invariants, transitions, and side effects

HARD-GATE

text

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

Map entry points: Start from controllers, jobs, services, APIs, and UI flows that expose business behavior.
Name the contexts: Group flows and rules by business capability, not by current folder names alone.
Find leakage: Look for terms, validations, workflows, or side effects crossing context boundaries.
Check ownership: Decide which context should own invariants, transitions, and external side effects.
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.

Examples

Good: Context Leakage Finding

ruby

# Fleet::Reservation confirms booking rules,
# but Billing::InvoiceService reaches into reservation state transitions directly.

Finding: Billing is orchestrating Fleet state changes. The boundary is unclear. Billing should react to a domain outcome from Fleet, not mutate Fleet internals directly.

Bad: Pattern-First Review