ddd-devops-integration

DDD DevOps 統合

DDD プロジェクト向けの DevOps — CI/CD における ArchUnit 品質ゲート（P0 はブロック／P1 は警告／P2 はレポート）、マルチモジュールのインクリメンタルビルド、アーキテクチャタイプを考慮した Dockerfile、イベント駆動型 DB マイグレーション、ドメインイベントの健全性監視。

---

ワークフロー

ステップ 1：コードとビルド — すべてのモジュールをコンパイルします。ドメインは最後にコンパイルし、フレームワークへの依存をゼロにします。

ステップ 2：ユニットテスト — モジュールごとのユニットテストを個別に実行します。

ステップ 3：ArchUnit による検証 — P0（依存ゼロ、レイヤー準拠）は CI をブロックし、P1（循環依存なし）は警告し、P2（命名）はレポートします。

ステップ 4：統合テスト — イベントストアとアウトボックスを使って、モジュール間の連携をテストします。

ステップ 5：コンテナ化 — Docker イメージをビルドします（モノリスの fat JAR、または JVM 引数を調整した CQRS 分割構成）。

ステップ 6：デプロイ — BC ごとの名前空間、DB マイグレーション用 init コンテナ、ヘルスプローブを使って K8s にデプロイします。

ステップ 7：監視 — ドメインメトリクス（イベント発生率、アウトボックスの深さ、集約の負荷）から Prometheus アラートを設定します。

品質ゲートはビルド時に実行し、本番環境では実行しません。違反があればデプロイではなく、マージをブロックします。

---

対応範囲

✅ 得意なこと

• DDD プロジェクト向けに ArchUnit 品質ゲート（P0/P1/P2）を設定し、CI/CD パイプラインに統合する
• マルチモジュール DDD プロジェクトのインクリメンタルコンパイルを最適化する（Maven/Gradle）、並列ビルドを高速化する
• アーキテクチャタイプを考慮した Dockerfile を生成する（モノリス/CQRS/ヘキサゴナルアーキテクチャ）
• K8s デプロイテンプレート：BC ごとの名前空間、DB マイグレーション用 init コンテナ、ドメインヘルスプローブ
• イベント駆動型データベースマイグレーション：イベントストア、アウトボックステーブルの作成とインデックス戦略
• ドメインイベントの健全性を監視する：Prometheus メトリクスの公開とアラートルールの設定

⚠️ 必要な情報

• プロジェクト構成：Maven/Gradle のモジュール一覧、依存関係図 → ArchUnit ルールを自動生成します
• デプロイ環境：K8s クラスターのバージョン、Ingress ポリシー → 環境に適した YAML テンプレートを生成します
• データベース方式：Layered/CQRS/Event Sourcing のどのパターンを採用しているか → マイグレーション戦略をカスタマイズします

❌ 対象範囲外（適用できません）

• 汎用 CI/CD 設定（DDD プロジェクト以外には適用できません）→ 汎用 DevOps ツールを使用してください
• コンテナオーケストレーションの基礎（K8s 入門チュートリアル）→ 公式ドキュメントを参照してください
• K8s クラスター運用（ノード管理、RBAC 設定）→ 専門の運用ツールを使用してください
• 汎用データベース管理（バックアップ、復元、パフォーマンスチューニング）→ DBA ツールを使用してください
• インフラストラクチャ監視（CPU、メモリ、ネットワーク）→ Prometheus + Grafana を使用してください

---

対象ユーザー

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

ルール

1. ArchUnit の P0 チェック（ドメインの純粋性、レイヤー準拠）が失敗した場合、CI パイプラインをブロックする必要があります。
2. Dockerfile はアーキテクチャタイプを考慮する必要があります（モノリス/CQRS/ヘキサゴナルでそれぞれ異なるビルドを行います）。
3. 本番環境へのデプロイ前に、ドメインイベントの監視を設定する必要があります。
4. イベント駆動型システムのデータベースマイグレーションには、イベントストアとアウトボックスのテーブルを含める必要があります。

---

CI/CD パイプライン

stages:
  - build
  - unit-test
  - architecture-check    # DDD gate
  - integration-test
  - containerize
  - deploy

architecture-check ステージで ArchUnit 検証を行います。P0 テスト（DomainPurityTest、LayeringComplianceTest）は失敗するとブロックし、P1（ModuleDependencyTest）は承認を求める警告を出し、P2（NamingConventionTest）はレポートのみを出します。主な ArchUnit ルール：ドメインは Spring/JPA/MyBatis に依存してはなりません。レイヤーへのアクセスを制限します（Domain にアクセスできるのは Application、Infrastructure、Interface のみ）。パッケージ間の循環依存を禁止します。詳しいガイド：references/ci-cd-archunit-setup.md

---

マルチモジュールビルド戦略

ddd-project/
├── domain/ (zero framework deps) → application/ (depends on domain only) → infrastructure/ (implements domain interfaces)
├── adapter/ (REST/event adapters) → start/ (boot entry)

ビルドの最適化：mvn compile -pl domain -am（変更部分のみのビルドで約 60% 高速化）、mvn -T 4（並列実行で約 40% 高速化）、mvn verify -pl '!domain'（domain をスキップ）、target/ に対する actions/cache（約 80%）。Maven Enforcer によりドメインの純粋性を確保します（domain モジュールでの Spring 依存関係を禁止）。設定の詳細：references/multi-module-build-config.md

---

コンテナ化とデプロイ

モノリス — マルチステージの fat JAR：

FROM eclipse-temurin:17-jdk-alpine AS builder
COPY . . && RUN mvn clean package -DskipTests
FROM eclipse-temurin:17-jre-alpine
COPY --from=builder start/target/*.jar app.jar
HEALTHCHECK --interval=30s CMD curl -f http://localhost:8080/actuator/health

CQRS — イメージを分離します：Command（-Xms512m -Xmx2g -XX:+UseZGC、CPU 最適化）；Query（-Xms1g -Xmx4g、メモリ最適化）。K8s パターン：BC ごとの Namespace、Flyway を使った DB マイグレーション用 initContainers、CQRS 分割用 HorizontalPodAutoscaler、NetworkPolicy による分離。テンプレート：dockerfile-patterns.md | k8s-ddd-reference.md

---

データベース移行（イベント駆動）

CREATE TABLE domain_event_store (id UUID PRIMARY KEY, aggregate_id VARCHAR(36) NOT NULL,
    event_type VARCHAR(200) NOT NULL, event_data JSONB NOT NULL,
    occurred_at TIMESTAMPTZ NOT NULL, published BOOLEAN DEFAULT FALSE);
CREATE INDEX idx_events_pending ON domain_event_store(published) WHERE published = FALSE;
CREATE TABLE outbox_message (id UUID PRIMARY KEY, event_id UUID UNIQUE NOT NULL,
    payload JSONB NOT NULL, status VARCHAR(20) DEFAULT 'PENDING',
    retry_count INT DEFAULT 0, created_at TIMESTAMPTZ DEFAULT NOW());
CREATE INDEX idx_outbox_pending ON outbox_message(status) WHERE status = 'PENDING';

戦略：レイヤード型の単一 DB → Flyway/Liquibase による順次移行、CQRS L2 → 2 系統 + 遅延、イベントソーシング → Axon/EventStoreDB による追記専用、マイクロサービスごと → BC ごとの Flyway。スクリプトの全容：flyway-migration.md | db-strategies.md

---

監視とアラート

バスメトリクス：domain.events.published（カウンター）、domain.events.processing.duration（ヒストグラム p50/p95/p99）、domain.aggregate.load.duration（ヒストグラム）、domain.outbox.depth（ゲージ）。

アラートルール：DomainEventBacklog（レート > 100 が 2 分間継続、重大）、OutboxQueueGrowing（深さ > 1000 が 1 分間継続、重大）、EventProcessingErrorRate（> 5% が 2 分間継続、警告）。設定の全容：ddd-observability-config.md

---

注意点

1. ArchUnit が厳しすぎて開発が滞る：まず警告モードで 2～3 スプリント実行し、P1/P2 は CI をブロックしないようにします。チームが慣れた後、エラーに切り替えます。
2. CQRS の読み取り用と書き込み用のコンテナが分離されていない：コマンドサービスは CPU 負荷が高く、クエリサービスはメモリ負荷が高いため、個別にビルドしてデプロイする必要があります。
3. ドメインイベントの監視漏れ：イベント配信の遅延、Outbox の滞留、Consumer Lag は、イベント駆動アーキテクチャで最も見落としやすい信頼性指標です。
4. モノリスをそのままマイクロサービスのイメージにする：まず BC を個別にデプロイする必要があるか評価します。過度に分割すると、集約内で強い整合性を保てる利点が失われます。
5. データベース移行でイベントストアを考慮していない：Event Store のテーブルを追加する際は、バックフィル、インデックス、クリーンアップの方針も併せて検討する必要があります。
6. ArchUnit はリッチドメインモデルをチェックしない：ドメインモデルの品質レビューには ddd-code-reviewer も併用する必要があります。

---

よくある質問

Q: ArchUnit の CI が失敗しますが、コードは正しいです。 A: Domain 層がフレームワークのアノテーション（@Service など）で汚染されていないか確認し、該当するものをインフラストラクチャ層に移してください。 Q: モノリスとマイクロサービスでは、DDD のデプロイ戦略はどう異なりますか？ A: モノリスから始めてください。BC に個別のスケーリングが必要な場合、単一 BC のチームが 8 人を超える場合、または BC 間でデプロイの頻度に大きな差がある場合にのみ分割します。 Q: 遅延を増やさずにドメインイベントを監視するにはどうすればよいですか？ A: 非同期メトリクス（Micrometer Timer のパーセンテージサンプリング）とサンプリングトレース（OpenTelemetry で 1/100）を使用します。イベントのパブリッシュを決してブロックしないでください。 Q: CQRS の読み取りと書き込みで同じパイプラインを共有すべきですか？ A: 共有するのは Domain モジュールのテストだけです。Command パイプラインでは ArchUnit の全ゲートを実行し、Query パイプラインでは読み取りモデルのスキーマ互換性に重点を置きます。 Q: Event Sourcing のスキーマはどのように管理しますか？ A: Event Store は追記専用なので、スキーマ移行は不要です。互換性はイベントのバージョン番号（event_type + version）で管理します。 Q: Bounded Context のカナリアリリースはどのように実装しますか？ A: Service Mesh（Istio）でトラフィックの重みを割り当てます。新バージョンにはまずトラフィックの 5% を流し、ドメインイベントの健全性指標を監視してから全量を流します。

---

セキュリティと安全性

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

キーワード

ddd devops、ddd ci/cd、archunit ci、domain event monitoring、ddd docker、ddd kubernetes、ddd outbox、ddd database migration、ddd build optimization、ddd quality gate、ddd deployment、ddd alerting、ddd observability、cqrs deployment、event sourcing infrastructure

参考資料

• CI/CD ArchUnit セットアップ — ArchUnit の CI/CD 統合ガイド
• Dockerfile のパターン — DDD アーキテクチャの種類別 Dockerfile
• K8s DDD リファレンス — Bounded Context 向け K8s デプロイ
• Flyway ドメインイベント移行 — Event Store と Outbox のスクリプト
• 監視とアラート — Prometheus メトリクスとアラートルール
• マルチモジュールビルド設定 — Maven/Gradle のビルド最適化
• DDD オブザーバビリティ設定 — Micrometer/OTel/Logback の設定
• GitLab CI パイプラインリファレンス — GitLab CI のパイプライン全体
• データベース移行戦略 — イベント駆動型の移行戦略

例

• GitHub Actions パイプライン — ArchUnit を含む GitHub Actions ワークフロー全体
• GitLab CI ArchUnit パイプライン — アーキテクチャ検証を含む GitLab CI
• K8s DDD デプロイ — Bounded Context のデプロイ用 K8s マニフェスト
• Flyway ドメインイベント移行 — 移行用 SQL スクリプト一式
• Grafana ドメイン健全性ダッシュボード — ドメインイベント監視ダッシュボード