ドメイン分離階層
ドメインアーキテクチャを定義するときに、プロセスとワークフローを追跡するための階層を作成します。
ドメイン分離階層の例
次の図は、ドメインアーキテクチャを定義するための適切な開始点を示しています。これは、TOP および下位のドメイン間の関係性と、プロセス、データ、およびビジネスルールが親および子ドメインにどのように影響するかを示しています。
- 次の例では、TOP がプロセスドメインです。これにユーザーを含めることはできません。むしろ、TOP には、インスタンスオーナーが開発する新しいプロセスと、これらのプロセスへのグローバルドメインからの上書きを含める必要があります。
- サービスプロバイダー (SP) のみがデフォルトドメインにアクセスできます。このドメインには、アクティブなユーザーは含まれません。ここには、正しいドメインに再アサインする必要がある「消失」データのみがあります。 注:データが特定のドメインにアサインされていない場合、デフォルトドメインに移されます。これは一時的に「消失」した状態であり、正しいドメインにアサインする必要があります。
- ドメインの作成時または更新時に、ドメインのないタスクとユーザーは自動的にデフォルトドメインに配置されます。このアクションを上書きするには、このレコードの [デフォルト] オプションをクリアするか、別のドメインレコードの [デフォルト] オプションを選択します。デフォルトドメインをまだ設定していない場合、ドメインのないタスクとユーザーはグローバルドメインに移されます。
- インスタンスを使用している間は、ドメイン間でデータを移動しないでください。
- デフォルトドメインで終了するデータがある場合は、対応するべき構成または手続きの問題があることを意味します。
グローバルドメインは存在しないため、この図には「グローバル」という語は表示されません。「グローバル」とは、レコードにドメインが存在しないことを意味します。
たとえば、[ドメイン] フィールドを持たないテーブルは、テーブルにすべてのグローバルレコードが含まれていることを意味します。[ドメイン] フィールドを含むテーブルは、ドメインのないレコードがグローバルドメインであることを意味します。
[ドメイン] フィールドには「グローバル」という語があります。レコードにドメインがない場合は、自動的にそこに配置されます。
インスタンスのすべてのユーザーは、セキュリティ構成によって制限されていない限りグローバルレコードを利用できます。
- グローバルレコードを含めるべきでないテーブルにグローバルドメインに留まるレコードが存在しないように、デフォルトドメインを使用してください。
- インスタンス所有者は、デフォルトドメイン内のレコードをトリアージし、正しいドメインに移動する必要があります。
ドメイン階層
- 親/子： 影響を受けるプロセスとデータ
- プロセスフローに基づく設計。
- 親ドメインが子ドメイン内のすべてのデータにアクセスできることに注意してください。
- ドメインを「含む」： 影響を受けるのはデータのみです。たとえば、図の SP に TOP が含まれるようにしても、TOP ドメイン以下で SP のプロセスは実行されません。
- 特定のドメインへの専用アクセスが必要なグループ内の個々のユーザーに、データアクセス権を付与します。
- データベースクエリーに追加される原因または条件が含まれ、大規模なドメインやデータセットでパフォーマンスの問題が発生する可能性があります。
- 可視性：アクセス権を付与したユーザーに常に表示される階層。影響を受けるのはデータのみで、プロセスは影響を受けません。
- 親/子階層の構築時にアクセス権が付与されなかった別のドメインに対して、ドメインのデータアクセス権を付与します。
- ユーザーがどのレコードを使用しているかにかかわらず、可視性アクセス権を付与されているドメイン内のすべてのデータの表示をユーザーに許可します。 注:可視性は、意図しないような完全なアクセスが許可されてしまうため、慎重に使用してください。
ドメイン階層を定義する基本原則
ドメイン分離の無制限および制限付きユースケース
多くの SP には、ドメインへのアクセスを厳密に制限する必要があることを暗黙的に示す顧客が含まれています。この場合、TOP ドメインでの「包含」機能の使用が制限されます。次の図では、ドメインを制限付きドメインと無制限ドメインに分割することで、その規制を軽減する方法について説明します。
-
顧客は、ドメイン分離階層の特定の「バーティカル」に存在します。つまり、そのドメインと、階層内でそのドメインの上位にあるすべての親ドメインで定義されたプロセスのみを消費します。直線的な親子階層にないドメインで定義されたプロセスは適用されません。
注:顧客または「テナント」は、互いに完全に分離されたエンティティであり、互いにリソースを共有する部門や事業部門とは異なります。 - スーパーバーティカル (制限付き、マネージャーサービスなど) は、顧客がどちらか一方にしか属さないのであれば、許可されます。
- すべての顧客が水平に利用できる必要があるサービス、製品、またはオファリングは、個別のドメイン階層内で定義されていません。
サンプルのユースケースは以下のとおりです。
- TOP の下で、[制限なし] と [制限付き] の 2 つのドメインを作成できます。
- SP の可視性制限がない顧客とそのドメインを [制限なし] ドメインに配置します。
- この要件がある顧客とそのドメインを [制限付き] ドメインに配置します。
- これにより、システム管理者は、効率的かつターゲットを指定する方法で「包含」および「可視性」機能を使用できます。
- 「包含」を [制限なし] に適用すれば、1 つの「包含」により、ほとんどの顧客に可視性を付与することができます。
- ドメインの可視性は、必要に応じて特定のドメインに対して「ドメイン可視性グループ」を使用して適用します。
次の図は、適切な階層モデルを選択する方法を説明しています。ドメイン構造に必要なプロセスと機能に応じて、個別の階層、ハイブリッド型、または共有階層を選択できます。
階層アーキテクチャの詳細については、「サービスプロバイダー参照アーキテクチャ」を参照してください。