テナント管理処理をパッケージとして実装してほしい

[koichimurakami]

MBC CQRS サーバーレスはマルチテナントアーキテクチャとなっている。
内部では テナントコードを保持しており、テナント毎にデータを分割できる構成となっている。

現在テナントコードを手動で管理していて手動管理となっているため、統一的な管理が出来るようにパッケージとして実装をしてほしい

機能の概要

• テナントの追加
• テナントの更新
• テナントの削除(論理)
• 共通テナント設定(システム設定)
• 個別テナント設定

ユーザ等で共通管理する情報は共通テナント、個別テナントに所属させる。
共通テナントには共通管理する情報(例えば名前や生年月日等)を設定し、個別テナントではテナント固有の管理情報(ニックネーム等)を管理する。

設定情報

設定情報は以下のレベルで管理したい。
同じ設定コードであるが、下位に行くほど設定有効とする。

• 共通テナントレベル
• 個別テナントレベル
• グループレベル
• ユーザレベル

※ 設定用パッケージは別途作成するか、本パッケージで行うか悩むがスキーマーは設計する必要がある

[quangquandev]

@koichimurakami
お手数ですが、念のため、次の認識をいくつか確認させていただけますでしょうか。

• テナントの追加、編集、削除、設定情報を行う権限があるのはシステム管理者だけですか？

[koichimurakami]

@quangquandev

テナントの追加、編集、削除、設定情報を行う権限があるのはシステム管理者だけですか？

システムによってはテナントの追加をユーザからの入力に基づき行うケースがあると思います。
テナント管理者が自分のテナントについて編集、削除を行なう事が出来る必要があります。

設定情報の設定は設定レベルにより変更出来るユーザが違います。

• 共通テナントレベルの設定 (システム管理者)
• 個別テナントレベルの設定 (システム管理者・テナント管理者+テナントユーザも行えるケースもある)
• グループレベルの設定 (システム管理者・テナント管理者・グループ管理者+グループユーザも行えるケースもある)
• ユーザレベルの設定 (ユーザ + システム管理者・テナント管理者がリセットするケースもある)

[koichimurakami]

グループレベルの設定データの取得ロジックをどうするか検討する必要があります。
例えば下記のような状態でユーザがグループ1-2、グループ1-4の設定のどちらを取得するべきか検討する必要がある。

ユーザの所属グループ

"groups": [
  "1",
  "1#2",
  "1#2#3",
  "1#4",
  "5"
]

ユーザ一覧の設定データ: UserListSetting

• 共通テナント: TENANT#common
• 個別テナント: TENANT#mbc
• グループ1: GROUP#1
• グループ2: GROUP#1#2
• グループ4: GROUP#1#4
• ユーザ: USER#abc

設定コード

• common#UserListSetting
• mbc#UserListSetting
• mbc#GROUP#1#UserListSetting
• mbc#GROUP#1#2#UserListSetting
• mbc#GROUP#1#4#UserListSetting
• mbc#USER#abc#UserListSetting

[quangquandev]

@koichimurakami グループレベルの設定データを取得するロジックを考える際、以下のルールを決める予定です。

設定の優先順位を定義する

設定を取得する際の優先順位を明確にする必要があります。次のようなルールが考えられます：

1. 最も具体的なグループ設定（例: 1#2#3）
2. 上位グループ設定（例: 1#2）
3. オリジナルグループ（Default設定）

この優先順位を適用することで、設定が上書きされる仕組みを実現できます。アルゴリズム設計

以下のようなアルゴリズムで設定を取得することができます：

• ユーザーが属するグループリストを取得（例:

"groups": ["1", "1#2", "1#2#3", "1#4", "5"]

• リスト内のグループIDを、特定の優先順位でチェック。
• 具体的には、グループIDを最も深い階層から順に（例: 1#2#3 → 1#2 → 1）調べる。

最初に見つかった設定データを返す。

例: 設定データ

以下のように各グループレベルで設定が存在していると仮定します：

• グループ 1: 設定A
• グループ 1#2: 設定B
• グループ 1#2#3: 設定C
• グループ 1#4: 設定D

例: ユーザー所属グループ
ユーザーが次のグループに所属しているとします：

"groups": ["1", "1#2", "1#2#3", "1#4", "5"]

1. 設定取得のフロー
2. 1#2#3 の設定が存在するかチェック → 見つかる (設定C)。
3. そのまま設定Cを返す。

[koichimurakami]

@quangquandev
ありがとうございます。
グループの優先順位に基づき決定するのは良いと思います。
ただ、グループの優先順位は別の目的に使用されてしまう可能性もあるので、設定の優先順位用のフィールド setting_groups を追加して groups から計算若しくは手動で設定するのはいかがでしょうか？

グループの設定優先順位を手動で設定するとした場合のデータ構成

"groups": ["1", "1#2", "1#2#3", "1#4", "5"],
"setting_groups": ["1#2#3", "1#2", "1#4", "1", "5"],
"setting_groups_mode": "customized", 

グループの設定優先順位を自動で設定するとした場合のデータ構成

1. 最も下の階層(優先)を→上の階層(劣後)
2. 同じ階層の場合はグループの優先順位に従う

"groups": ["1", "1#2", "1#2#3", "1#4", "5"],

setting_groups を自動生成し、setting_groups_modeをautoに設定して下記のデータとしてグループ設定時に設定関連データを保管する

"groups": ["1", "1#2", "1#2#3", "1#4", "5"],
"setting_groups": ["1#2#3", "1#2", "1#4", "1", "5"],
"setting_groups_mode": "auto", 

[quangquandev]

@koichimurakami
ありがとうございます。
以下はパッケージのインターフェース定義の予定です。
2つのインターフェースがあります。1つはテナント管理用、もう1つは設定管理用です。

ITenantService

interface ITenantService {
  /**
   * Retrieves the current tenant code associated with a specific key.
   *
   * @param key - The key used to identify the tenant code details.
   * @returns A promise that resolves to the tenant code's data entity.
   */
  getTenantCode(key: DetailKey): Promise<DataModel>

  /**
   * Creates a new tenant code based on the provided data.
   *
   * @param dto - The data transfer object containing the parameters required for creating a tenant code.
   *  dto contains:
   *   - name: string - The name of the setting.
   *   - code: string - The code of the setting.
   *   - description: string .
   *   - attributes: object - The setting data.
   *     Example TenantCodeEntity:
   *      + COMMON
   *       - pk: TENANT#COMMON
   *       - sk: ''
   *       - id: TENANT#COMMON
   *       - attributes: object
   *       - name: COMMON
   *       - type: string
   
   *      + Tenant MBC
   *       - pk: TENANT#COMMON
   *       - sk: mbc
   *       - id: TENANT#COMMON#mbc
   *       - attributes: object
   *       - name: MBC
   *       - type: string


   * @param options - Additional options including the invocation context.
   * @returns A promise that resolves to the newly created tenant code's data entity.
   */
  createTenantCode(
    dto: CreateTenantDto,
    options: {
      invokeContext: IInvoke
    },
  ): Promise<Record<string, any>>

  /**
   * Updates an existing tenant code with new data.
   *
   * @param options - Options including the invocation context.
   * @returns A promise that resolves to the updated tenant code's data entity.
   */
  updateTenantCode(
    dto: UpdateTenantDto,
    options: { invokeContext: IInvoke },
  ): Promise<CommandModel>

  /**
   * Deletes an existing tenant code identified by the specified key.
   *
   * @param key - The key used to identify the tenant code to delete.
   * @param options - Additional options including the invocation context.
   * @returns A promise that resolves to the data entity of the deleted tenant code.
   */
  deleteTenantCode(
    key: DetailKey,
    options: { invokeContext: IInvoke },
  ): Promise<CommandModel>

ISettingService

interface ISettingService {
  /**
   * Retrieve tenant code, user ID, and group settings from Cognito.
   * Fetch settings from DynamoDB in the order of levels: user => group => tenant => common.
   * Return the settings result for the user.
   * @param key - The key used to identify the setting e.g. UserListSetting
   * @returns A promise that resolves to the setting s data entity.
   */
  getSetting(
    key: string,
    options: { invokeContext: IInvoke },
  ): Promise<DataModel>

  /**
   * Creates a new setting code based on the provided data.
   *
   * @param dto - The data transfer object containing the parameters required for creating a setting.
   * dto contains:
   *   - name: string - The name of the setting.
   *   - code: string - The code of the setting.
   *   - tenantCode: string - The tenantCode of the setting, e.g., (COMMON, MBC, MAI).
   *   - type: string - The type, which can be common, tenant, group, or user.
   *   - entityIdentifier: string - The group identifier, e.g., (group:1, 1#2, 1#4, 1#2#3), (user:abc).
   *   - attributes: object - The setting data.
   *     Example SettingEntity:
   *     - User level:
   *       - pk: SETTING#mbc#USER#abc
   *       - sk: UserListSetting
   *       - id: SETTING#mbc#USER#abc#UserListSetting
   *       - attributes: object
   *       - name: UserListSetting
   *       - type: USER
   *     - Group level:
   *       - pk: SETTING#MBC#group2#4
   *       - sk: UserListSetting
   *       - id: SETTING#mbc#group#2#4#UserListSetting
   *       - attributes: object
   *       - name: UserListSetting
   *       - type: GROUP
   *     - Tenant :
   *       - pk: SETTING#MBC
   *       - sk: UserListSetting
   *       - id: SETTING#mbc#UserListSetting
   *       - attributes: object
   *       - name: UserListSetting
   *       - type: Tenant
   *     - COMMON:
   *       - pk: SETTING#COMMON
   *       - sk: UserListSetting
   *       - id: SETTING#COMMON#UserListSetting
   *       - attributes: object
   *       - name: string
   *       - type: string
   * @param options - Additional options including the invocation context.
   * @returns A promise that resolves to the newly created setting's data entity.
   */
  createSetting(
    dto: CreateSettingByTenantDto,
    options: {
      invokeContext: IInvoke
    },
  ): Promise<CommandModel>

  /**
   * Updates an existing setting with new data.
   *
   * @param options - Options including the invocation context.
   * @returns A promise that resolves to the updated tenant code's data entity.
   */
  updateSetting(
    dto: UpdateSettingDto,
    options: { invokeContext: IInvoke },
  ): Promise<CommandModel>

  /**
   * Deletes an existing setting identified by the specified key.
   *
   * @param key - The key used to identify the tenant code to delete.
   * @param options - Additional options including the invocation context.
   * @returns A promise that resolves to the data entity of the deleted tenant code.
   */
  deleteSetting(
    key: DetailKey,
    options: { invokeContext: IInvoke },
  ): Promise<CommandModel>
}

[koichimurakami]

@quangquandev
ISettingService について createSetting を 低レベルのFunctionとして作成する事は良いですが、ユーザが使う高レベルのFunctionとして、 createCommonTenantSetting 、 createTenantSetting、 createGroupSetting、 createUserSetting を作成するようにして下さい。
高レベルのFunctionについてはDBの構造をそのままDtoにするのではなくユーザが保存したいデータをDtoとなるように設計してもらえますか？ pk、sk、type等を高次元のFunctionにセットさせたくないです。attributes の名称も低レベルでは使用しても良いと思いますが、高レベルでDBの構造をそのまま使うのは避けたいので settingValue のような名前にして、保存時に attributes にすると言った処理にした方が良いと思います。

ITenantService についてテナントの追加・更新・削除をしたいので、名称としては createTenantCode 、updateTenantCode、 updateTenantCode ではなく、createTenant 、updateTenant、 updateTenant の方が適切です。
また、低レベルのFunctionも必要ですが、高レベルFunctionも検討してもらえますか？