前置き
ドメイン駆動設計のコアドメイン、補完ドメイン、一般ドメインはそれぞれ、
・サーバーレスで運用するのか、それとも自分たちのコンテナで運用するのか？
そして、
・CI/CDパイプラインでは、各領域どのようにリリースするのか？
をそれぞれ見ていきましょう。
運用環境 (サーバーレス vs コンテナ)
DDDの各ドメインタイプに応じた運用環境は以下の通りです。
🚀 コアドメイン
競争優位性の源泉であり、ロジックが複雑で変更も頻繁です。
状態管理や長時間の処理が必要な場合も多いため、コンテナ (K8sなど) で運用するのが基本です。これにより、最大の柔軟性と制御性を確保します。
⚙️ 補完ドメイン
コアドメインを支えるが、差別化要因ではありません。
ロジックが比較的単純でステートレスな場合、運用コスト削減のためにサーバーレス (FaaS) が適しています。
ただし、特定の要件（状態管理、長時間実行）があればコンテナも選択肢になります。
🧩 一般ドメイン
認証、決済、メール送信など、業界標準で解決できる問題です。可能な限り外部SaaSを利用するのが最善です（自分たちで運用しない）。自作する場合でも、ロジックは安定・単純なため、サーバーレスが最適です。
CI/CDパイプラインでのリリース戦略
DDDの各ドメインタイプに応じたCI/CDリリース戦略は以下の通り。
🧩 一般ドメイン (外部SaaS利用)
リリース対象外
ここは、自分たちでデプロイするものではありません。
自分たちで実装したアプリケーションからAPIを呼び出して利用するだけです。
パイプライン
アプリケーションのパイプライン内で、外部SaaSとの**連携テスト（コントラクトテストなど）**を行う程度です。
コアドメイン & 補完ドメイン (自作)
理想
DDDの境界に基づき、それぞれが独立したエンドツーエンドパイプラインを持ちます。
これにより、各ドメイン（特にコアドメイン）が他のドメインに影響されずに、自律的に高速なリリース（ビルド、テスト、デプロイ）を行えます。
現実 (移行期など)
ドメイン間の結合が残っている場合（例：分散モノリス）、ファンインパイプラインモデル（ビルド/テストは並列、デプロイは集約）になることもあります。
戦略
・コアドメインのパイプライン
最も高度な設計原則（OCP, 適応度関数など） を適用し、変更への対応力と信頼性を最大化します。
・補完ドメインのパイプライン
比較的シンプルな構造でも許容される場合がありますが、コアドメインの変更をブロックしないように疎結合を保つことが重要です。