DDD code review + anti-pattern detection + 5-dimension compliance scoring. Verify whether the code follows DDD best practices and output a structured review report.
Workflow
DDD code review in three steps:
Step 1: 代码扫描 — 反模式检测清单逐项检查 + 源代码扫描
Step 2: 评分计算 — 5 维度逐项评分（分层/领域/命名/结构/测试）
Step 3: 报告输出 — 结构化审查报告（评分 + 反模式列表 + 修复建议）
Every review must complete all three steps and output a complete report. Only verbally describing problems without outputting a document means the team cannot track improvements.
When to Use
Trigger words (use when triggered)
代码审查 DDD review 反模式检测 anti-pattern 贫血模型 充血模型检查 架构审查 分层合规 代码质量评分 layering compliance rich domain check review my DDD code
Applicable prerequisites
| Condition | Description |
|---|---|
| The project has already adopted DDD concepts | Non-DDD projects have no basis for review |
| There is reviewable source code | Code paths or snippets need to be provided |
| Expectation to find anti-patterns | Not just format checking, but more focused on domain model health |
Inapplicable scenarios
| Skip | Switch to |
|---|---|
| Non-DDD projects (pure CRUD) | Standard code review (SonarQube / Checkstyle) |
| The project has not yet introduced DDD | ddd-architecture-awesome(learn DDD concepts first) |
| Just finished writing the first DDD code | Finish writing first, then review |
| Need architecture selection | ddd-architecture-selector |
| Need architecture health assessment | ddd-architecture-evaluator |
Audience
This skill is designed for: Backend developers (implementing DDD architectures), Software architects (evaluating and selecting patterns), Tech leads (reviewing team implementations), and DDD beginners (learning domain-driven design fundamentals).
Rules
- Every code review must include a 5-dimension scoring report.
- P0 anti-patterns (anemia model, layer violation, cross-aggregate ref) block merge.
- Domain layer must have zero framework dependencies — verified via ArchUnit.
- Review reports must include fix suggestions ordered by priority (P0→P1→P2).
Anti-Pattern Checklist
12 DDD anti-patterns, graded by P0 (block merge) / P1 (fix before next version) / P2 (continuous improvement).
- P0 — Must fix: Anemic model, god Service, direct cross-aggregate references, domain layer framework dependencies, circular dependencies, Repository returning non-aggregate roots
- P1 — Should fix: Controller business logic, Application Service containing SQL, mutable value objects
- P2 — Continuous improvement: Aggregate too large, missing domain events, cross-aggregate transactions
See the complete anti-pattern quick reference table in references/checklist.md, including Java code examples and fix paths.
Layered Compliance Matrix
Layered dependency check rules (based on ArchUnit):
┌─────────────────┬─────┬─────┬─────┬─────┐
│ 层 / 可依赖 │ Infra│ Dom │ App │ Adap│
├─────────────────┼─────┼─────┼─────┼─────┤
│ Infrastructure │ ✓ │ ✗ │ ✗ │ ✗ │
│ Domain │ ✗ │ ✓ │ ✗ │ ✗ │
│ Application │ ✓ │ ✓ │ ✓ │ ✗ │
│ Adapter │ ✓ │ ✓ │ ✓ │ ✓ │
└─────────────────┴─────┴─────┴─────┴─────┘
Domain layer zero-dependency rule (P0)：
- ✗
import org.springframework.stereotype.Service - ✗
import javax.persistence.Entity - ✗
import org.apache.ibatis.annotations.Mapper - ✓
import java.util.Optional - ✓
import java.math.BigDecimal
See the complete ArchUnit configuration in references/archunit-config.md。
Rich Domain Model Validation
Rich models encapsulate behavior in entities (pass); anemic models expose state via getters/setters (fail). Key: behavior in Entity vs behavior in Service.
See the complete code examples and refactoring comparisons in examples/rich-model-refactoring.md, including 3 real-world cases.
Scoring System
5-dimension scoring
| Dimension | Weight | Check items | Full score |
|---|---|---|---|
| 1. Layering compliance | 30% | Domain zero dependencies, dependency direction, App without SQL, Controller without business logic | 30 |
| 2. Domain model quality | 30% | Rich model coverage, value object usage rate, aggregate design, domain events | 30 |
| 3. Naming conventions | 15% | Aggregate root = business name, Repository = standard naming, events = past tense | 15 |
| 4. Code structure | 15% | Packages organized by aggregate, class size, cyclomatic complexity | 15 |
| 5. Test coverage | 10% | Domain layer test coverage, aggregate root behavior tests, event verification | 10 |
Total score = Σ(dimension score × weight)
Score grades
| Range | Grade | Meaning | Action |
|---|---|---|---|
| ≥ 85 | 🟢 A | Excellent DDD practices | Can go to production |
| 70-84 | 🟡 B | Basically compliant, with room for improvement | Fix P1 issues |
| 50-69 | 🟠 C | Obvious anti-patterns exist | Plan a refactoring Sprint |
| < 50 | 🔴 D | Requires large-scale refactoring | Block merge; refactoring must be done first |
See the scoring criteria and calculation examples at references/scoring-criteria.md、examples/scoring-example.md。
Review Report Template
Each review outputs a structured report, including:
# DDD Code Review Report
## Overall Score: 78/100 (🟡 B)
### 分层合规 (24/30)
| 检查项 | 结果 | 说明 |
|--------|:----:|------|
| Domain 零依赖 | ✅ | 无框架依赖 |
| App 层无 SQL | ❌ | OrderAppService L45 直接调用 Mapper |
| 依赖方向 | ✅ | 无反向依赖 |
### 领域模型质量 (22/30)
| 检查项 | 结果 | 说明 |
|--------|:----:|------|
| 充血模型 | ⚠️ | User 实体仍为贫血模型 |
| 值对象 | ⚠️ | Money/Email 已用，Phone 仍为 String |
### 反模式清单
| 严重级别 | 反模式 | 位置 | 修复建议 |
|:------:|--------|------|---------|
| P0 | 上帝 Service | OrderService.java:45-320 | 拆分为 OrderPricingService + OrderFulfillmentService |
### 改进建议（按优先级）
1. [P0] 将 OrderAppService 中的 SQL 移到 Repository 实现
2. [P1] 将 User 实体改为充血模型
3. [P2] 为关键业务操作补充领域事件
See the full template at references/report-template.md, and examples at examples/review-report-example.md。
Gotchas
See common review pitfalls at references/gotchas.md。
FAQ
| Question | Answer |
|---|---|
| How long does one review take? | About 30-60 minutes for small projects (1-2 aggregates); for large projects, review by module in multiple sessions |
| Is scoring subjective? | Each check item has clear detection criteria (see references/scoring-criteria.md), and is repeatable and verifiable |
| Do I have to write the ArchUnit checks myself? | Use the configuration in references/archunit-config.md directly; just copy it into the project |
| What should I do if I find an anti-pattern but cannot change it? | Fix P0 issues first. Record P1/P2 as technical debt and create a repayment plan |
| Recommended review frequency? | Code reviews are recommended before PR merges. Architecture-level reviews are recommended once per quarter |
| How does it differ from reviewing non-DDD architecture? | DDD reviews focus on domain model health, while non-DDD reviews focus on code standards/performance/security |
Security & Safety
This skill is pure documentation. It contains no executable scripts, collects no user data, accesses no external services or networks.
Keywords
DDD code review, anti-pattern detection, anemic model, rich model, god Service, layered compliance, dependency direction, ArchUnit, domain events, value object immutability, aggregate design, 5-dimension scoring, code quality gates
References
| File | Purpose |
|---|---|
| references/checklist.md | Anti-pattern quick reference — P0/P1/P2 classification + remediation paths |
| references/scoring-criteria.md | 5-dimension scoring criteria — weight and detection method for each check |
| references/archunit-config.md | Complete ArchUnit configuration — Maven/Gradle dependencies + full set of check rules |
| references/report-template.md | Review report template — Markdown + quick summary format |
| references/clean-ddd-hexagonal-layers.md | Detailed explanation of the four-layer architecture structure — Domain/App/Infra/Presentation |
| references/clean-ddd-hexagonal-tactical.md | DDD tactical pattern reference — Entity/VO/Aggregate/Repository |
| references/clean-ddd-hexagonal-testing.md | Testing patterns — unit testing/integration testing/architecture testing |
| references/partme-15-boundaries.md | Microservice boundary theory — logical boundaries/physical boundaries/code boundaries |
| references/gotchas.md | Common review pitfalls — cross-aggregate references, PO/DTO mixing, etc. |
Examples
| File | Purpose |
|---|---|
| examples/review-report-example.md | Complete review report example (62/100 🟠 C grade) |
| examples/scoring-example.md | Full scoring calculation process + remediation ROI analysis |
| examples/rich-model-refactoring.md | Anemic→rich model refactoring: 3 practical cases |
| examples/anti-pattern-fix-guide.md | Anti-pattern remediation path quick reference |
| examples/archunit-compliance-test.md | ArchUnit compliance testing — P0/P1/P2 gate implementation |
Next Steps
After the review is complete, proceed to subsequent steps based on the results:
- Architecture-level assessment →
ddd-architecture-evaluator - Repair the architecture directory structure → corresponding architecture Skill (
ddd-architecture-layered/ddd-architecture-hexagonal/ddd-architecture-cola, etc.) - Improve test coverage →
ddd-testing-strategist - Output architecture documentation →
ddd-architecture-doc