ddd-boundaries-review

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

DDD Boundaries Review

DDD边界审查

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.

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.

代码仓库似乎在同一个模型或服务命名空间下混合了多个业务概念。
团队在权责归属、边界划分或规则放置位置上存在争议。
Rails架构审查发现存在跨域耦合问题。
下一步： 当上下文边界足够清晰可进行战术建模时，串联使用
```
ddd-rails-modeling
```
；当边界需要增量抽离时，串联使用
```
refactor-safely
```
。

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.

映射入口点： 从暴露业务行为的控制器、任务、服务、API和UI流程开始。
命名上下文： 按业务能力对流程和规则分组，不要仅依据现有文件夹名称划分。
查找泄漏： 排查跨上下文边界的术语、校验规则、工作流或副作用。
核对权责： 确定哪个上下文应该负责不变量、状态流转和外部副作用。
提出最小可信改进方案： 在尝试大规模重组前先进行重命名、抽离、隔离或封装操作。

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

undefined

ruby

undefined

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.


- **发现：** Billing模块正在编排Fleet的状态变更，边界不清晰。Billing应该响应Fleet发出的领域事件，而不是直接修改Fleet的内部状态。

Bad: Pattern-First Review

反面示例：优先套用设计模式的审查

ruby

undefined

ruby

undefined

Bad review:

"Create five bounded contexts and event buses"

without naming the business capabilities or ownership conflicts first.

undefined

undefined

Common Mistakes

常见错误

Mistake	Reality
"Everything should become a bounded context"	Many apps only have a few real contexts; over-splitting creates ceremony
Reviewing folders without reviewing language	Directory structure alone does not prove domain boundaries
Solving context leakage with shared utility modules	Shared utils often hide ownership problems instead of fixing them
Recommending a rewrite first	Start with the smallest credible boundary improvement

错误认知	实际情况
"所有内容都应该拆成限界上下文"	多数应用只有少数几个真实上下文，过度拆分只会增加不必要的流程
只审查文件夹结构不审查术语体系	仅目录结构无法证明领域边界的合理性
用共享工具模块解决上下文泄漏问题	共享工具通常会隐藏权责问题而非解决它们
优先推荐重写	从最小可信的边界改进开始

Red Flags

风险信号

One model serves unrelated workflows with different language
Multiple services mutate the same concept with different rules
Cross-context constants, callbacks, or direct state changes are common
People describe ownership with "whoever needs it" instead of a named context

单个模型为使用不同术语的无关工作流提供服务
多个服务用不同规则修改同一个概念
跨上下文的常量、回调或直接状态变更很常见
人们用「谁需要谁负责」而非明确的上下文来描述权责归属

Integration

技能联动

Skill	When to chain
ddd-ubiquitous-language	When the review is blocked by fuzzy or overloaded terminology
ddd-rails-modeling	When a context is clear and needs entities/value objects/services modeled cleanly
rails-architecture-review	When the same problem also needs a broader Rails structure review
refactor-safely	When the recommended improvement needs incremental extraction instead of a rewrite

技能	串联时机
ddd-ubiquitous-language	当审查因术语模糊或过载受阻时
ddd-rails-modeling	当上下文边界清晰，需要对实体/值对象/服务进行清晰建模时
rails-architecture-review	当同一问题还需要更全面的Rails结构审查时
refactor-safely	当推荐的改进方案需要增量抽离而非重写时