mcpField
D
ddd-testing-strategist

ddd-testing-strategist

github.com/full-stack-skillsテスト・品質17123 回インストール4 週間前に更新
リポジトリ

ddd-testing-strategist について

DDD プロジェクトのテスト計画を支援するガイドです。バックエンド開発者やアーキテクト向けに、ドメイン層やアーキテクチャに応じたテストピラミッド、モック方針、TDDD、CI/CD、N+1 クエリ検出を扱います。

主な機能

  1. 01DDDの各層とテストピラミッドを計画
  2. 02値オブジェクト、集約、リポジトリのテスト方針
  3. 03アーキテクチャに応じたモック方法
  4. 04テスト駆動ドメイン設計の手順
  5. 05CI/CD、カバレッジ、N+1検出を解説
  6. 06CQRSとEvent Sourcingのテストを提案

活用シーン

  1. 01DDDプロジェクトの層別テスト計画
  2. 02集約とドメインサービスのテスト設計
  3. 03リポジトリや外部ポートのモック方針選定
  4. 04アーキテクチャテストとN+1検出をCIに追加

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/full-stack-skills/ddd-skills --skill ddd-testing-strategist

インストール後、Claude Code で/ddd-testing-strategistを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

agents/
openai.yaml
examples/
01-app-adapter-test-examples.md
02-architecture-test-examples.md
03-builder-mock-patterns.md
04-cqrs-es-test-examples.md
05-domain-test-examples.md
references/
01-architecture-testing-comparison.md
02-ci-cd-test-stages.md
03-clean-ddd-hexagonal-testing.md
04-cqrs-event-sourcing-testing.md
05-integration-test-strategies.md
06-mock-integration-patterns.md
07-test-coverage-targets.md
08-test-driven-domain-design.md
09-testing.md
10-unit-testing-strategies.md
references/guides/
.gitkeep
references/patterns/
.gitkeep

詳細

DDD テストストラテジスト

DDD テスト戦略 — 値オブジェクトの単体テストから、あらゆる DDD アーキテクチャにおけるエンドツーエンド検証までを扱います。DDD テストピラミッド、レイヤーごとのテストパターン、アーキテクチャ別のモック戦略、テスト駆動ドメイン設計(TDDD)、CI/CD パイプラインとの統合、N+1 クエリの検出を網羅します。

ワークフロー

用户输入 → 场景分类 → 输出测试策略 + 代码模板

Step 1: 按用户问题场景分类(金字塔/AR/Repository/Mock/CQRS/TDDD/CI-CD/覆盖率)
Step 2: 从 references 获取对应测试模板
Step 3: 按架构类型调整 Mock 策略
Step 4: 输出代码模板 + CI/CD 配置 + 覆盖率目标

使用する場面:ユーザーが DDD テスト戦略、集約ルートのテスト、Repository のテスト、モック戦略、CQRS のテスト、TDDD、CI/CD テスト統合について質問したときに起動します。

境界

✅ 対応できること
  1. DDD テストピラミッド(Domain 60% + Integration 20% + E2E 10% + Architecture 10%)
  2. 各レイヤーのテスト戦略:Value Object / Aggregate Root / Domain Service / Repository / Application / Adapter
  3. アーキテクチャの種類に応じたテスト(Layered / Hexagonal / Clean / COLA / CQRS / Event Sourcing)
  4. テスト駆動ドメイン設計(TDDD)の方法論
  5. モック戦略の選択(Mock Ports / Capture Events / Real DB)
  6. CI/CD の 3 段階パイプライン + N+1 クエリの検出 + ArchUnit によるアーキテクチャテスト
  7. テストカバレッジ目標の設定 + ブランチカバレッジの確認
⚠️ 条件が必要
  1. 既存の DDD プロジェクトのコードがある、またはドメインモデルを設計中である
  2. テストフレームワークが導入済みである(JUnit / Mockito / Spring Test / Testcontainers)
  3. DDD の戦術的パターンを理解している(Entity / VO / Aggregate / Repository / Domain Event)
❌ 対象範囲外(適用されない場面)
  1. DDD 以外のプロジェクトのテスト — 標準テストフレームワーク(JUnit / pytest / Jest)
  2. フロントエンドのみのテスト — Cypress / Playwright / Vitest
  3. パフォーマンス / 負荷 / セキュリティテスト — JMeter / k6 / OWASP ZAP
  4. 言語固有のテストチュートリアル — 概念とパターンは言語に依存しません
  5. DDD 以外のプロジェクトの CI/CD 設定

対象読者

このスキルは、バックエンド開発者(DDD アーキテクチャの実装担当)、ソフトウェアアーキテクト(パターンの評価と選定担当)、テックリード(チームの実装レビュー担当)、DDD 初心者(ドメイン駆動設計の基礎を学ぶ方)を対象としています。

ルール

  1. DDD テストピラミッドでは、Domain レイヤーのテストを最優先しなければなりません(全テストの 60%)。
  2. Domain レイヤーのテストでは、Domain Service や Aggregate Root をモックしてはいけません。モックできるのは外部ポートのみです。
  3. Repository の統合テストでは、モックではなく、実データベースを使用する Testcontainers を使わなければなりません。
  4. Event Sourcing プロジェクトには、イベントの再生テストとプロジェクションのテストを含めなければなりません。
  5. アーキテクチャ準拠テスト(ArchUnit)は CI パイプラインで実行しなければなりません。

DDD テストピラミッド

DDD のピラミッドと従来のピラミッドの主な違いは、Domain レイヤー(VO + AR + DS)がテストの中心であり、**60%**を占めることです。

         ╱           E2E Tests           ╲       ← 10%
        ╱──────── API Integration ────────╲       ← 10%
       ╱────── Repository Integration ──────╲     ← 10%
      ╱─────── Application Service ─────────╲    ← 10%
     ╱──────── Domain Service Tests ──────────╲   ← 15%
    ╱────────── Aggregate Root Tests ───────────╲  ← 25%
   ╱──────────── Value Object Tests ──────────────╲ ← 15%

各レイヤーのテスト戦略

① Value Object のテスト(純粋関数)
@Test void money_should_prevent_negative_amount() {
    assertThrows(IllegalArgumentException.class, () -> new Money(-1.0, "CNY")); }
@Test void money_add_should_sum_same_currency() {
    assertEquals(new Money(30.0, "CNY"), new Money(10.0, "CNY").add(new Money(20.0, "CNY"))); }

対象:コンストラクターでの検証、演算ロジック、等価性の比較、不変条件。

② Aggregate Root のテスト(中核となるビジネスロジック)
class OrderPayTest {
    @Test void pay_changes_status_to_paid_when_draft() { ... }
    @Test void pay_emits_orderPaidEvent() { ... }
    @Test void pay_fails_when_already_paid() { ... }
    @Test void pay_fails_when_cancelled() { ... } }

対象:状態遷移ごとに個別のテストクラスを作成 → 正常系 + 境界条件 + 不変条件 + イベント。

③ Domain Service のテスト(Repository をモックし、イベントをキャプチャ)
@Test void pricing_service_applies_vip_discount() {
    when(orderRepository.findById(order.getId())).thenReturn(Optional.of(order));
    pricingService.calculatePrice(order.getId());
    assertEquals(new Money(90.0, "CNY"), order.getTotalAmount()); }

モックの原則:Repository / Gateway(Interface)のみをモックし、Domain Service や Aggregate Root はモックしません。

④ Application Service + ⑤ Repository + ⑥ Adapter のテスト
@Test void place_order_creates_and_saves() {
    var orderId = handler.handle(new PlaceOrderCommand("cust-123", ...));
    assertNotNull(orderId); }
@SpringBootTest @Testcontainers
class OrderRepositoryImplTest {
    @Test void persists_and_retrieves_complete_aggregate() { ... } }
@SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)
class OrderControllerTest {
    @Test void post_orders_returns_201() { ... }
    @Test void post_invalid_product_returns_400() { ... } }

App Service:すべての外部ポートをモックします。Repository:Testcontainers + 実 DB。Adapter:MockMvc + 実 DB。

モック戦略マトリックス

テスト対象RepositoryGatewayEventBusExternal
Value ObjectN/AN/AN/AN/A
Aggregate RootN/AN/ACaptureN/A
Domain ServiceMockMockCaptureMock
Application ServiceMockMockMockMock
Repository IntegrationReal DBN/AN/AN/A
API IntegrationReal DBMockMockMock
E2EReal DBRealRealReal
原則:Domain レイヤーではモックは不要です。インターフェース(Port)のみをモックし、実装クラスはモックしません。ドメインイベントには Capture パターンを使用します。

アーキテクチャごとのテストの違い

アーキテクチャテストの重点違いの説明
LayeredAggregate Root + RepositoryDomain レイヤーを網羅的にテスト(60% 以上)
HexagonalPort Mock + Adapter Integrationインターフェースをモックすれば、外部全体をモックできます
CleanEntity + UseCase InteractorUseCase レイヤーでは出力ポートをモックします
COLADomain + App ServiceDomain は依存関係ゼロ。CQRS の振り分けも追加でテストします
CQRSCommand + Query Read Model書き込みモデルには集約テストを使用し、読み取りモデルではビューを直接クエリします
Event SourcingEvent Replay + Projection集約の再生テスト(必須)と、投影読み取りモデルのテスト

テスト駆動ドメイン設計(TDDD)

4 ステップのワークフロー:RED → GREEN → REFACT → REPEAT

@Test void tddd_order_should_not_allow_paying_twice() {
    Order order = Order.create(customerId, items);
    order.pay(mockGateway);
    assertThrows(OrderException.class, () -> order.pay(mockGateway)); }
public void pay(PaymentGateway gateway) {
    if (this.status == OrderStatus.PAID) throw new OrderException("Already paid");
    this.status = OrderStatus.PAID;
    addDomainEvent(new OrderPaidEvent(this.getId())); }

テストカバレッジ目標

レイヤー目標主要なカバレッジ対象
Value Object≥ 95%コンストラクターでの検証、演算ロジック、等価性の比較
Aggregate Root≥ 95%状態遷移(すべての経路)、ドメインイベント
Domain Service≥ 90%エンティティ間のオーケストレーション、外部データの計算
Application≥ 80%ユースケースの完全な経路 + 例外経路
Repository≥ 80%集約の完全性、N+1 クエリ
Adapter (API)≥ 70%プロトコル変換、エラーマッピング
ブランチカバレッジを優先して追跡することを推奨します。Domain レイヤーでは 90% 以上を目指します。

注意点 — よくある落とし穴

  1. App Service だけをテストし、Domain をテストしない — DDD の核心は Domain 層です。
  2. Domain Service を Mock する — Domain Service は Mock すべきではありません。
  3. 集約ルートの Happy Path だけをテストする — 不変条件違反と境界条件を必ずカバーしてください。
  4. Repository テストを E2E として扱う — Repository が検証するのは永続化のみです。
  5. Event Replay テストを忘れる — 最も見つけにくいバグの原因です。
  6. テストと実装を密結合させる — 内部の詳細ではなく、振る舞いをテストしてください。
  7. ドメインイベントをテストしない — 各業務メソッドでイベントの発行を検証してください。
  8. Testcontainers を使わず DB を Mock する — 常に実際のデータベースを使ってください。
  9. CQRS の Query 側をテストしない — Command 側と Query 側では戦略がまったく異なります。
  10. N+1 クエリを検出しない — CI で SQL カウント検出を統合してください。
  11. E2E テストが多すぎる — 重要なジャーニーを 3~5 個だけ残してください。
  12. ArchUnit を忘れる — 依存関係の方向の準拠を自動でチェックしてください。

FAQ

質問回答
集約ルートのテストに Spring は必要ですか?不要です。純粋な POJO なので、JUnit + AssertJ を直接使います。
Repository は Mock すべきですか、それとも実際の DB を使うべきですか?Domain Service では Mock を使い、Repository では実際の DB を使います。
CQRS の Query 側はどのようにテストしますか?読み取りモデルに直接アクセスすればよく、Mock は不要です。
Event Sourcing で必要なテストは何ですか?Event Replay です。イベントシーケンスを与えて → 再生し → 状態を検証します。
N+1 クエリを避けるにはどうすればよいですか?SQLStatementCountValidator を統合します。
TDDD と従来の TDD の違いは何ですか?TDDD は「ドメインの振る舞い/状態遷移」を単位とします。

キーワード

DDD テスト、テストピラミッド、集約ルートテスト、値オブジェクトテスト、ドメインサービステスト、Repository テスト、アプリケーションサービステスト、アダプターテスト、CQRS テスト、Event Sourcing テスト、TDDD、Mock 戦略、Testcontainers、ArchUnit、N+1 テスト、ドメインイベントテスト、分岐網羅率、CI/CD テスト、統合テスト、E2E テスト、イベント再生テスト

参考資料

ファイル用途
references/testing.mdテストピラミッド + 各層の TypeScript サンプル
references/mock-integration-patterns.mdMock の実装 + Java 統合テスト
references/clean-ddd-hexagonal-testing.mdClean/Hexagonal/DDD の多層テスト
references/unit-testing-strategies.mdVO/AR/DS の単体テスト + 状態遷移
references/integration-test-strategies.mdRepository/API の統合テスト + N+1
references/cqrs-event-sourcing-testing.mdCQRS + ES の再生/プロジェクション/スナップショットテスト
references/test-coverage-targets.mdカバレッジ目標 + 分岐網羅率 + JaCoCo
references/ci-cd-test-stages.mdCI/CD の 3 段階 + GitHub Actions
references/architecture-testing-comparison.md各アーキテクチャのテストの違い + プロジェクト段階別の戦略
references/test-driven-domain-design.mdTDDD の 4 ステップワークフロー + 完全な事例

例

ファイル用途
examples/domain-test-examples.mdVO + AR + DS の完全なテスト例
examples/app-adapter-test-examples.mdApp Service + Adapter + E2E
examples/cqrs-es-test-examples.mdCQRS + ES の再生/プロジェクション/スナップショットテスト
examples/builder-mock-patterns.mdBuilder + Mock Repository/EventPublisher
examples/architecture-test-examples.mdArchUnit によるアーキテクチャテスト(レイヤー化/集約の分離)

セキュリティと安全性

このスキルは純粋なドキュメントです。実行可能なスクリプトは含まず、ユーザーデータの収集や外部サービス/ネットワークへのアクセスも行いません。

DDD スキルの歩み

📍 現在地:ddd-testing-strategist — ステップ 6 ← 前へ:ddd-domain-designer スキルに引き継ぎます(インストール:npx skills add full-stack-skills/ddd-skills --skill ddd-domain-designer)。 → 次へ:ddd-devops-integration スキルに引き継ぎます(インストール:npx skills add full-stack-skills/ddd-skills --skill ddd-devops-integration)。 🔗 関連:ddd-code-reviewer スキル(インストール:npx skills add full-stack-skills/ddd-skills --skill ddd-code-reviewer) | ddd-cqrs-architecture スキル(インストール:npx skills add full-stack-skills/ddd-skills --skill ddd-cqrs-architecture)に引き継ぎます。 🏠 ホーム:ddd-architecture-awesome スキルに引き継ぎます(インストール:npx skills add full-stack-skills/ddd-skills --skill ddd-architecture-awesome)。

コメント