分離の仕組み
プラットフォームが共有するデータを除き、すべての業務テーブルには tenant_id 列があります。リクエストが届くと、フィルタチェーンがログイン中のアカウントが属するテナントを現在のスレッドにバインドし、Hibernate のテナントフィルターが自動的にクエリへテナント条件を付与し、書き込み時には tenant_id を自動的に埋めます。業務コードはテナント条件を「忘れる」ことができません。
テナントをまたぐ少数のシナリオ（ログイン時にユーザー名からアカウントを探す、テナントごとのアカウント数を集計する、バックグラウンドの定期タスクなど）では、明示的に「システムコンテキスト」に入る必要があるため、コードレビューですぐに見つけられます。
共有と独立
| プラットフォーム共有 | テナントごとに独立 |
|---|---|
| アプリケーションとリソースカタログ、API カタログ、OAuth クライアント、プラグイン | アカウント、部門、ユーザーグループ、職位、ロール、権限付与、割り当て、データとフィールドのポリシー、職務分離、申請と再確認、アイデンティティソース、データサービス、監査 |
ユーザー名はプラットフォーム全体で一意であるため、ログイン時にテナントを選択する必要はありません。
プラットフォームテナント
プラットフォームテナントは初期化時に作成され、停止することはできません。その管理者はプラットフォームが共有するデータと他のテナントを管理し、プラットフォームテナントのロールだけが「すべてのテナント」のデータ範囲を使用できます。
ID
すべての主キーは TSID です。64 ビットで時刻順に並び、クラスタ内ではノード番号によって一意性が保証されます。TSID は JavaScript が正確に表現できる整数よりも大きいため、JSON では常に文字列として受け渡します。クラスタ内の各インスタンスは、それぞれ異なる GRANTFORGE_ID_NODE が必要です。