前置き
一般的に、ドメイン駆動設計において、コアドメイン領域のインフラ部分はサーバーレスではなく、自分たちでコンテナ運用する必要があります。
ただ、PoCの段階やプロトタイプ作成時に関しては、素早く顧客からフィードバックをもらうために、【意図的】 にサーバーレスアーキテクチャにしてしまう方がいいです。
この 意図的に という部分がポイントです。
PoC、プロトタイプ段階でのFaaSの利用
PoC（概念実証）やプロトタイプの段階では、コアドメインであっても意図的にサーバーレスを選択することは、多くの場合、非常に効果的で現実的な戦略です。
これは、長期的なアーキテクチャの妥当さよりも、
短期的なスピードとフィードバックを優先し、いかにMVPに必要な品質特性を学ぶ
という意識的なトレードオフです。
なぜ初期段階では良い選択肢なのか
⚡️ 開発スピード
サーバーレス（FaaS）は、インフラ（Kubernetesクラスタ、ネットワーク、スケーリングなど）の設定・管理のオーバーヘッドを劇的に削減してくれます。
その結果、チームはコアビジネスロジックの実装に専念でき、迅速にデプロイできます。
🗣️ 高速なフィードバックループ
PoCの主な目的は、学習と検証です。
サーバーレスを使えば、動作するバージョンをはるかに早く顧客やステークホルダーに見せることができ、変更コストが最も安い初期段階で重要なフィードバックを集められます。
💰 低い初期コスト
トラフィックが少ない、または予測不能なプロトタイプの場合、サーバーレスの従量課金モデルは非常に費用対効果が高いです。
アイドル状態のコンテナインフラにコストを払う必要がありません。
計算されたリスク（なぜ「意図的」なのか）
このアプローチが「意図的」でなければならない理由は、以下の潜在的なデメリットがあるからです。
🚧 アーキテクチャのミスマッチ
サーバーレスの制約（ステートレス、実行時間制限など）が、将来的には複雑で進化するコアドメインの要求と衝突するリスクを受け入れます。
コアドメイン部分の特性を、サーバーレスでは満たせません。
なぜなら、サーバーレスアーキテクチャは、非同期でステートレスなイベント駆動アーキテクチャが前提だからです。
⚙️ 書き換え/リファクタリングの可能性
PoCが成功し進化した場合、後でアプリケーションの一部をコンテナで効果的に実行するために、リファクタリングや書き換えの時間が必要になる可能性を暗黙的に受け入れます。
これはスピードのために取る計画的な技術的負債です。
このアプローチを成功させるための考慮事項
この戦略を効果的に機能させるためには、以下の点が重要です。
明確な意思表示
チームは、なぜサーバーレスが選ばれたのか（PoCのためのスピード）を明確に理解し、
それがコアドメインにとって、一時的な選択 である可能性が高いことを認識する必要があります。
ロジックへの集中
サーバーレス関数内のコアドメインロジックを、FaaSインフラ自体から可能な限りクリーンに分離しておくこと（Lambda内でもヘキサゴナルアーキテクチャの原則を意識するなど）。
これにより、将来の移行が容易になります。
移行基準の定義
サーバーレスからの移行が必要になるトリガーを大まかに定義しておくこと
（例：「状態管理が複雑になりすぎた時」「長時間実行プロセスが必要になった時」
「パフォーマンス限界に達した時」）。
アナロジー
これは、短いトラック（PoC）で新しいエンジン設計を素早くテストするために軽量なレースカーを使うようなものです。（作りこみ過ぎないのがポイント）
たとえ最終製品が長距離輸送用の頑丈なトラック（本番のコアドメイン）である必要があっても、「今」の特定の仕事に適したツールを使うのです。