GoとPostgreSQL、Node.jsとSupabaseの違い

AIジェネレーターなら、どちらのスタックでももっともらしいSaaSプロトタイプを作れます。本当に差が出るのは、顧客が扱いにくいデータを作り、リトライが順不同で届き、クエリプランが変わり、誰かが本番障害を説明しなければならなくなった後です。最初の画面を最速で作れたものではなく、チームが障害の起き方を把握し、修復できるスタックを選びましょう。

GoとPostgreSQLは、アプリケーションとデータベースの境界を明示します。リクエストをどう受けるか、どこでトランザクションを始めるか、SQLをどう組み立てるか、バイナリをどう実行するかを自分で決めます。Node.jsとSupabaseは、JavaScriptまたはTypeScriptのランタイムに、認証、ストレージ、リアルタイム機能、生成API、ホスト型運用を含む、PostgreSQL中心の管理サービス群を組み合わせます。後者では準備作業を大きく減らせますが、アプリケーションロジックの置き場所と、どの運用判断を自分で担うかも変わります。

これは同等な二つのプログラミング言語セットではありません。一方は意図的に組み立てたバックエンドであり、もう一方は管理製品を中心としたアーキテクチャであることが多いものです。構文を比べたり、生成されたファイル数を数えたりしても、判断の核心は見えません。

二つのスタックで責任をどう分けるか

最初に決めるべきことは、バックエンドの契約をどこまで自分で持ちたいかです。GoとPostgreSQLでは通常、HTTP処理、認可判断、検証、トランザクション境界、バックグラウンド処理、データベースアクセスをサービスが担います。PostgreSQLは永続状態とデータベースの保証を担います。ホスティング、ID管理、オブジェクトストレージ、デプロイは、追加しない限り別の選択です。

Node.jsとSupabaseのアプリケーションでは、これらの責任が分散します。Nodeサービスやサーバーレス関数に独自ロジックを置く一方で、Supabaseはホスト型PostgreSQL、Auth、Storage、Realtime、Edge Functions、データベースから生成したAPIレイヤーを提供します。Row Level Security（RLS）の下では、ブラウザクライアントがSupabaseと直接やり取りできる場合もあります。一般的なエンドポイントのコードは減りますが、そのときデータベースポリシーは公開アプリケーション境界の一部になります。

この違いはGoとTypeScriptの違いより重要です。Goの生成RESTハンドラーとSupabaseの生成テーブル呼び出しは、同じくらい速く作れそうに見えます。Goのハンドラーには、リクエストを調べ、ルールを適用し、トランザクションを開き、トレースを出す明確な場所が残ります。直接テーブルを呼ぶ場合、データに触れる前に生成APIの挙動とRLSを通ることがあります。ソースコード上の経路は短くても、本番では必ずしも単純ではありません。

管理機能は無料のおまけではなく、アーキテクチャ上の約束として扱ってください。AuthがRLSで使うIDを発行し、Storageポリシーが同じIDを参照し、Realtimeサブスクリプションがデータベース変更に依存するなら、後で一部を置き換えると複数の契約に影響します。この結び付きは十分に合理的です。小さなチームにとって、まとまったサービスセットを購入する価値は大きいものです。問題は、チームがデータベースだけを選んだと思い込むときに始まります。

ジェネレーターがリポジトリ、サービスレイヤー、汎用ヘルパーだらけの内部フレームワークを作れば、GoとPostgreSQLでも依存関係は隠れます。エンジニアが追えないコードを所有しても役に立ちません。生成された抽象化によって、単純なSQL更新をRLSポリシーより見つけにくくなることもあります。まず最小で読みやすい境界を生成させ、次のレイヤーを足す前に結果を確認してください。

ワークロードの形でランタイムを決める

Goは、継続的な並行処理、混在するバックグラウンド作業、予測可能なメモリ要件、複数の協調処理でレイテンシが決まるエンドポイントを持つサービスに合います。goroutineを使えば並行I/Oを扱いやすく、コンパイル済みバイナリは運用者にとってコンパクトなデプロイ単位になります。だからといって、すべてのGoサービスが高速になるわけではありません。悪いSQL、無制限の並行性、タイムアウト不足は、よく知られた形で障害を起こします。

Node.jsは、ネットワークI/O、短いリクエストハンドラー、イベント処理が中心で、チームがすでにTypeScriptで生産性を発揮しているワークロードに合います。イベントループは、待機中の接続を多数効率よく処理します。CPU負荷の高い作業をメインスレッドで行うと進行を止めるため、画像変換、大きな文書の解析、ローカルのモデル関連計算には、ワーカースレッド、別ワーカー、または別サービスが必要です。デモ入力は小さいため、生成コードではこの境界が無視されがちです。

Supabaseは、一般的なデータアクセス、認証フロー、ファイルストレージ、データベース主導のリアルタイム更新で、アプリケーション側の作業を減らせます。初期版の中心がアカウント、フォーム、レコード、権限、通知である製品には強く合います。すべての操作が多くの外部システムを調整する場合、長時間ジョブが必要な場合、ドメインルールをデータベースポリシーや小さなエッジ関数に置けない場合には、適合度が下がります。

選ぶ前に、ワークロードについて次の四つを考えてください。

• 一つのユーザー操作は単一レコード操作で済むか、それとも複数の集約にまたがるトランザクションが必要か。
• リクエストの大半はネットワーク待ちか、それとも意味のあるCPU処理を行うか。
• ジョブはHTTPリクエストより長く続き、リトライ、リース、キャンセル、進捗追跡を必要とするか。
• データベースで認可をきれいに表現できるか。それとも権限は外部状態やワークフロー履歴に依存するか。

請求データのインポートがこの違いを示します。ファイルのアップロード、メタデータ保存、進捗表示は、どちらのスタックにも合います。不規則な何千行もの解析、既存請求書との重複排除、アカウント固有ルールの適用、部分失敗後の再開には、明示的なジョブモデルが必要です。Goはそのようなワーカーに向いています。Nodeでも、チームがCPU作業を分離し、永続キューを持てば実現できます。Supabaseはデータベースとストレージの層として引き続き役立ちますが、ジョブの意味論を消してはくれません。

性能が重要になるかもしれないという理由だけでGoを選ばないでください。若いSaaSの大半は、ランタイムのスループットが制約になる前に、クエリ、製品、運用上の誤りにぶつかります。明示的な並行性と長時間動くプロセスがサービスの形に役立つときに選びます。AIモデルがTypeScriptを流暢に出力するからという理由だけでNodeを選ぶのも避けてください。Web境界をまたいで一つの言語を使うことが、ワークロードと運用する人に役立つときに選びます。

チームのスキルが生成コードのコストを変える

最適なスタックは、ジェネレーターが間違えた後にチームがデバッグできるものです。レビュー担当者が更新の取りこぼし、安全でないポリシー、awaitされなかったPromiseを認識できなければ、生成速度に大きな価値はありません。

Goを本番運用した経験があるチームは、明示的なハンドラー、型付きドメイン構造、context.Contextによるキャンセル、直接SQLを好むことが多いでしょう。Goのコンパイラーは接続まわりのミスを有用な範囲で検出しますが、トランザクションが正しい行を保護しているか、認可チェックが業務ルールに合っているかまでは証明できません。レビュー担当者には引き続きデータベースの判断力が必要です。

TypeScript中心のチームは、フロントエンドとバックエンドの型が馴染みのあるツールを共有するため、NodeとSupabaseのコードベースを素早く進められます。スキーマを基準にする場合、Supabaseが生成するデータベース型はエディター上のフィードバックを改善します。型だけで実行時検証が行われるわけではなく、型アサーションはレビュー担当者に必要だった警告を黙らせることがあります。生成コードは、外部入力がすでに望む形だと断言しがちです。

スキルには、チームの運用上の語彙も含まれます。推測せずにEXPLAIN (ANALYZE, BUFFERS)を読める人はいるでしょうか。RLSのUSING式とWITH CHECK式を区別できるでしょうか。拒否されたPromiseを通じて非同期Nodeハンドラーを追えるでしょうか。Goのコネクションプール飽和を調べ、キャンセルを伝播できるでしょうか。はいと答えられる項目が多いスタックほど、運用リスクは低くなります。

小規模チームは、コンテキストスイッチも数えるべきです。GoとPostgreSQLでは、マイグレーション、認証、ストレージ、キュー、可観測性、ホスティングを別々に選ぶ必要があるかもしれません。各選択が良くても、統合作業は発生します。NodeとSupabaseはその表面積の多くを一製品に集め、TypeScriptをフロントエンドの近くに保ちます。節約できる注意力は現実のものです。

反対側のコストは専門知識です。RLSの下でブラウザから直接アクセスするなら、すべてのレビュー担当者がデータベースポリシーをアプリケーションの認可として理解する必要があります。エッジ関数には、通常のNodeサーバーとは異なるランタイム境界があります。ホスト型ダッシュボードは日常作業を楽にしますが、バージョン管理されたマイグレーションの外で本番状態を変えたくなる誘惑もあります。これらはSupabaseを選べない理由ではありません。見積もりに入れてください。

チームの誰もどちらのスタックも運用したことがないなら、独立した可動部品が少ない設計を選び、移行経路を書き残してください。レコード中心のSaaSなら、多くの場合はSupabaseです。ジョブ、連携、独自ワークフローを中心にするバックエンドなら、クライアント呼び出し、ポリシー、関数、トリガーにロジックを分散するより、マネージドPostgreSQLを使う小さなGoサービスのほうが考えやすいことがあります。

クエリを制御できることは製品を制御できること

SQLの形とトランザクションの挙動が製品の中心なら、直接PostgreSQLへアクセスするGoを選びます。通常のCRUDが中心で、RLSが無理なくセキュリティモデルを表せるなら、Supabaseの生成データアクセスを選びます。

PostgreSQLのドキュメントはトランザクション分離を正確に説明しています。Read Committedがデフォルトであり、一つのトランザクション内で連続する二つのコマンドは、異なるコミット済みデータを見る可能性があります。チームは、分離レベルとロックの挙動を決めないまま「トランザクションがあれば操作は安全」と安心できる言葉を繰り返しがちです。トランザクションは作業をまとめます。すべての競合を自動で防ぐわけではありません。

二つのワーカーが次の保留中エクスポートを取得するケースを考えてみましょう。読み取りの後に更新すると、両方のワーカーが同じ行を見られてしまいます。取得は一つのデータベース操作にし、意図的にロックを使います。

BEGIN;

WITH next_job AS (
  SELECT id
  FROM export_jobs
  WHERE status = 'pending'
  ORDER BY created_at
  FOR UPDATE SKIP LOCKED
  LIMIT 1
)
UPDATE export_jobs AS j
SET status = 'running',
    started_at = now(),
    worker_id = $1
FROM next_job
WHERE j.id = next_job.id
RETURNING j.id, j.account_id, j.payload;

COMMIT;

結果は、id、account_id、payloadを含む取得済みの一行か、利用可能なジョブがない場合はゼロ行です。SKIP LOCKEDは別々の行を処理してよいキュー型コンシューマーに適しています。ロックされた行を意図的に除外するため、ユーザー向け読み取りの万能薬ではありません。

Goでは、この文を明示的なトランザクションとキャンセル期限を持つリポジトリまたはクエリパッケージに置けます。Nodeでは、サーバー側のデータベースクライアントが同等の関数やSQL呼び出しを実行できます。生成Supabase APIでは、複雑なロックロジックは一般にRPC経由で公開するPostgreSQL関数へ移ります。ここでも堅実なPostgreSQLですが、レビュー担当者はリクエストハンドラーではなく、マイグレーションとデータベース関数を見に行く必要があります。

RLSにも同じ精度が必要です。PostgreSQLはテーブルとコマンドごとにポリシーを評価します。USING句はコマンドが既存行のどれを見られるかを制御し、WITH CHECK句は新規または変更行のどれを作れるかを制御します。読み取りを絞るポリシーだけでは、挿入と更新に関するすべての不変条件を自動では表せません。少なくとも匿名ID、通常メンバー、別テナントのメンバー、権限の高いサービスロールでポリシーをテストしてください。

生成CRUDは、繰り返し書くエンドポイントコードをなくせるため魅力的です。本当にテーブル形の契約である操作には使い続けてください。複数レコードにまたがる不変条件、冪等性、ワークフロー遷移は、サーバー境界か慎重に設計したデータベース関数の後ろに置きます。製品ルールを説明するのに一段落必要なら、クライアントコードと複数のRLSポリシーに散らすと、次のインシデントは長引きます。

移植性は守る境界に左右される

GoとPostgreSQLは、アプリケーションがバイナリであり、データベースが標準PostgreSQLプロトコルを話すため、通常はより明確なデプロイ移行経路を提供します。サービスはコンテナでもホスト上でも実行でき、多くのPostgreSQLプロバイダーから選べます。プロバイダー固有の拡張、文書化されていないインフラ、環境前提を避けなければ、移植性は保てます。

SupabaseはPostgreSQLを使うため、独自データベースよりはるかに優れたデータ移行経路があります。データベースダンプでテーブル、インデックス、関数、トリガー、ポリシーモデルの大部分を保持できます。ただしアプリケーション全体は、Authトークンクレーム、Storageオブジェクトの規約、Realtimeの挙動、エッジ関数、生成APIの意味論、シークレット、デプロイ設定にも依存するかもしれません。データベースを移すことと、システムを移すことは別です。

リリース前に移植性の棚卸しを作りましょう。依存関係をデータベース、ID、ファイル、非同期処理、ランタイム、デプロイに分けて記録します。それぞれについて、コードが利用する契約と置き換えコストを書きます。役立つ問いは、移行が可能かどうかではありません。時間をかければほぼ何でも可能です。通常のリリースチームが製品作業を続けながら移せるかを問うてください。

AI生成SaaSでは、所有するものを検査、実行できなければ生成アプリは役立たないため、ソースのエクスポートも重要です。Koder.aiはデプロイとホスティングに加え、ソースコードのエクスポートを支援しているため、チームは生成を不透明な終着点として扱わず、生成されたReactとGo/PostgreSQLアプリをレビューできます。それでも、生成環境の外でクリーンビルドをテストする必要はあります。

このクリーンビルドは早い段階で行ってください。空のマシンまたは最小コンテナから始め、マイグレーションからデータベースを復元し、文書化された環境変数を渡し、テストを実行して、代表的な一つのリクエストを処理します。次に、実際のバックアップから非本番環境へ復元します。ベンダー変更や障害まで移植性テストを待つチームは、すでに高価な選択をしています。

データの場所も移植性を決めることがあります。契約上、特定の国でアプリケーションを動かす必要があるなら、ランタイム、データベース、バックアップ、ログ、オブジェクトストレージ、サポートアクセスのすべてがその要件に合うか確認してください。Webプロセスだけを移しても、データシステムは移りません。Koder.aiはデータプライバシーと越境移転の要件に応じて異なる国でアプリケーションを実行できますが、チームは自分たちのアーキテクチャにある、データを持つコンポーネントをすべて対応付ける必要があります。

デバッグで複雑さの行き先が見える

GoとPostgreSQLでは、デバッグはリクエストトレース、サービスログ、データベースセッション、ジョブワーカーに集まりやすい傾向があります。Node.jsとSupabaseでは、同じ調査がブラウザ呼び出し、Nodeプロセスまたはエッジ関数、生成APIログ、Auth、RLS、Realtime、PostgreSQLにまたがる場合があります。アプリケーションコードの行数が少なくても、確認すべき境界が増えることがあります。

よくある障害は、一見無害なスキーマ変更から始まります。生成アプリがnullableなorganization_idを追加し、一部の行をバックフィルし、RLSポリシーを有効にして、クライアントクエリを変更します。通常経路のアカウントは動きます。古い行がnullのままでポリシーに隠されます。クライアントは明示的な認可エラーではなく空の結果を受け取り、空の状態を描画します。Realtimeサブスクリプションは別のフィルターを使い、変更を通知し続けます。サポートには、更新後にだけ再び表示されることがある画面が見えます。

この一連に珍しいことは何もありません。難しいのは各判断を観察することです。調査者には、認証済み主体、トークンクレーム、リクエストID、データベースロール、SQLまたは生成API操作、ポリシー結果、行数、サブスクリプションチャネル、デプロイ済みスキーマバージョンが必要です。これらの事実が共通のリクエスト値やユーザー相関値を持たない別々のダッシュボードにあれば、チームは時刻を頼りにインシデントを再構成します。

従来型のGoエンドポイントなら、クエリ前に存在しない組織をドメインエラーに変換し、一つの構造化イベントをログに残し、定義済みステータスを返せます。この明示性は役立ちます。同時に、ハンドラーがテーブルへの唯一の経路であることを前提にしています。忘れられた管理エンドポイントやワーカーは、データベースが同じ不変条件を強制しない限り、同じ認可を回避できます。

Supabase設計なら、すべてのクライアント経路でPostgreSQLにテナント分離を強制できます。これも有用です。障害モードはポリシーの見えにくさです。空の行セットは正しいフィルタリング、不正なIDコンテキスト、不完全な移行データ、クエリの不具合のどれでもあり得ます。本番でRLSを無効にせず、これらを区別できる診断操作を用意してください。

どちらのスタックでも、生成される各バックエンド経路に四つの項目を求めてください。相関ID、認証済みアクターID、操作名、スキーマまたはリリースバージョンです。機密データを明かさない範囲で、処理時間と行数を記録します。元のエラー原因を保持しつつ、安全なクライアント応答へ変換します。Nodeではリクエスト境界で拒否されたPromiseを処理し、プロセスレベルのハンドラーを復旧策と扱わないでください。Goではリクエストコンテキストをデータベース呼び出しに渡し、期限切れのキャンセルとデータベース障害を区別します。

デバッグしやすさは設計上の性質です。ジェネレーターが運用者に追えないコードを作るなら、ログを至る所に足す前に制御フローを単純化するよう求めてください。

デプロイの手軽さと運用責任は別

Supabaseは、最初の運用ラウンドではたいてい有利です。チームはプロジェクトを用意するだけで、各コンポーネントを組み立てずにデータベースと統合サービスを受け取れます。バックアップ、アップグレード、サービス可用性、プラットフォーム監視には管理されたデフォルトまたは製品上の設定があります。保持期間と制限は変わり得るため、正確な内容は現在のプランとプロバイダーの文書を確認してください。

マネージドは放置してよいという意味ではありません。アプリケーションチームは、スキーマ設計、インデックス、高価なクエリ、接続の挙動、データ保持、RLSの正しさ、シークレット、アプリケーション監視、復旧テストを担います。クォータと、どの障害でプロバイダーの支援が必要になるかも理解しなければなりません。データベースが健全だと示すダッシュボードでも、あるテナントのレポートが誤ってシーケンシャルスキャンをしていることまでは教えてくれません。

GoとPostgreSQLでは、責任がより見えやすくなります。マネージドPostgreSQLを選ぶなら、プロバイダーがデータベース機構の大部分を担い、チームはサービスランタイムを担います。両方をセルフホストするなら、パッチ適用、フェイルオーバー、バックアップ、復元訓練、容量、インシデント対応も担います。セルフホストは本気の証明ではありません。人員と訓練が必要な運用負荷です。

接続管理は両スタックで問題になります。長時間動くGoサービスはプールを使い、オープン接続数、アイドル接続数、接続寿命、リクエスト期限に明示的な上限が必要です。サーバーレスNode関数は、適切なプーラーを使い、トランザクションモードの制約を守らなければ、PostgreSQLを圧倒するクライアントの急増を起こします。リクエストごとに新しいクライアントを開く生成コードは、デモでは生き残ってもトラフィック急増時に崩れます。

マイグレーションには一つの権限主体が必要です。順序付きでバージョン管理されたマイグレーションを、制御されたデプロイ手順から実行します。各サービスインスタンスに起動時のスキーマ変更を競わせたり、ダッシュボード編集を文書化されていない本番の真実にしたりしてはいけません。拡張と縮小の変更はデプロイの結び付きを減らします。互換性のある列やテーブルを追加し、両方の形を扱うコードをデプロイし、バックフィルし、読み取りを切り替え、後のリリースで古い形を削除します。

バックアップは、復元が成功して初めて価値を持ちます。隔離環境への復元を予定し、アプリケーションレベルの事実を確認してください。ユーザーが認証できること、テナント境界が保たれること、ファイルがデータベース参照と合うこと、予定ジョブが二重実行されないこと、代表的なワークフローが完了することです。この作業はどちらのスタックにも必要です。管理型の選択肢が変えるのは、バックアップ機構を誰が動かすかであり、復元した製品が正しいかを誰が判断するかではありません。

プロトタイプ速度は誤った証拠を作り得る

最初のプロトタイプが測るのは、ジェネレーターが作るよう促された経路を、そのスタックがどれだけ速く処理するかです。競合、部分失敗、ポリシーの進化、復元、六か月後の新しいエンジニアの調査をシステムがどう扱うかは測りません。

Node.jsとSupabaseは、信頼できそうなレコード中心製品までの経路を短くできることが多いです。認証、データベースアクセス、ストレージ、リアルタイム挙動は、別々のベンダー選定や統合なしで使えます。TypeScriptジェネレーターには模倣できるパターンが豊富にあります。創業者が人々がそのワークフローを望むか検証する段階なら、この速度は理論上の移植性の懸念を上回ることがあります。

GoとPostgreSQLは、リスクのある部分がバックエンドの挙動にある製品で、より良い証拠を生むことが多いです。明示的なAPIとワーカーなら、冪等性、ロック、レート制限、連携リトライ、ドメイン境界を早く試せます。最初のユーザーインターフェースの到着は速くないかもしれませんが、最も壊れやすい部分をプロトタイプで動かせます。

Supabaseで始めて後で書き直せばよいという人気の助言は、気軽すぎます。多くの製品は書き直しを必要とせず、早期検証が重要なので、この助言は広まっています。しかし、プロトタイプがRLSに認可を、トリガーにワークフローを、プロバイダークレームにIDを、Storageの規約にファイルを、Realtimeサブスクリプションにイベントの挙動を置き、それらすべてを一時的だとチームが呼んでいるなら誤りです。書き直しは、そのとき重要な契約をすべて同時にまたぎます。

反対に、スケールするから今すぐきれいなGoサービスを作るという助言も弱いものです。製品にその価値があると誰かが知る前に、エンドポイントの配管、デプロイ、サービス境界に貴重な時間を使う可能性があります。使われないアーキテクチャの稼働率は完璧です。

画面ではなく、リスクをプロトタイプにしてください。テナントポリシーが難しいなら、代表的なRLSルールを作り、テナント横断テストで攻めます。バックグラウンド処理が難しいなら、重複配信、タイムアウト、キャンセル、再起動を通じてワーカーを動かします。移植性が契約上必要なら、データベースを復元し、二つ目の環境にアプリケーションをデプロイします。非技術者の創業者が製品を維持しなければならないなら、生成画面から実際のスキーマとワークフローの変更を行ってもらい、生成された差分を確認します。

プランニングモード、スナップショット、ロールバックは、生成を伴う反復を安全にできます。しかし、アプリケーションコードを以前のスナップショットへ戻せても、データベースのロールバックはタイムマシンにはなりません。顧客データを削除または書き換えるスキーマ変更には、バックアップと前方復旧計画が必要です。

リリース後のシステムのための判断マトリクス

独自のサーバー挙動が製品で最も難しい部分であり、チームがGoを運用でき、SQLの制御が重要で、置き換え可能な契約を持つデプロイコンポーネントが欲しいなら、GoとPostgreSQLを選びます。製品が主に認証済みデータワークフローで、チームがTypeScriptに習熟し、統合サービスが意味のある準備作業を減らし、RLSで権限を明確に表せるなら、Node.jsとSupabaseを選びます。

実際の製品を次の基準で一から五まで評価し、チームメンバー間で一点を超える差が出たすべての評価を話し合ってください。

列の合計を機械的に比べないでください。製品を終わらせかねない二つか三つの基準に重みを付けます。医療ワークフローでは、データの場所と認可が開発速度より上位かもしれません。社内承認ツールでは、提供速度と馴染みのあるTypeScriptのほうがはるかに重要かもしれません。データインポート製品は、ワーカーの復旧とクエリ制御で成否が決まることがあります。

境界が明確なら、ハイブリッド設計も正当です。TypeScriptのWebアプリがAuthと通常のテーブルAPIを使う一方で、GoワーカーがSupabase PostgreSQLに対して長時間ジョブを処理できます。Nodeのフロントエンドサービスが、トランザクションワークフローを担うGo APIを呼ぶこともできます。同じ状態を両側が変更でき、不変条件を担う主体が一つもないとき、ハイブリッドは害になります。

生成前に一ページのアーキテクチャ記録を書いてください。ワークロード、各不変条件の責任主体、トランザクション境界、非同期ジョブモデル、IDの出所、ファイルの所有権、デプロイ先、復旧方法、移植性の制約を記します。そして、生成コードにその選択を証明させます。プロンプトの質は役立ちますが、アーキテクチャ記録があれば、ジェネレーターが最も多く見た例に従って難しい部分をひそかに決めることを防げます。

チームが、失敗したリクエストを説明し、顧客状態を復元し、業務ルールをどこにあるか推測せず変えられるようになったとき、スタックの判断は完了です。その三つの仕事を日常的にできる設計を選んでください。