ドメインでモデルを分類する

1. このページで伝える機能

ドメインは、モデル（エンティティ）を業務領域ごとに分類するための情報です。「営業管理」「会計管理」などの分類を用意し、各モデルをいずれかのドメインへ紐づけます。

大規模なアプリケーションでは、モデルが増えるほど、それぞれがどの業務に属するかを把握しにくくなります。ドメインで分類すると、設計情報を読む開発者やAIが、業務ごとの構成や変更対象を整理しやすくなります。

現時点では、ドメインの設定はビルドするアプリケーションに影響しません。設計情報を管理しやすくするために使います。

2. Wagby11で実現できること

2.1 業務領域ごとにモデルを整理する

例えば、営業と会計を扱うアプリケーションで、次のように分類できます。担当業務を説明しながらモデルを探したり、変更を依頼する範囲を伝えたりするときの手がかりになります。

モデル区分のマスタ（M）・トランザクション（T）・選択肢（O）は、データの用途を表します。ドメインは業務領域の分類なので、同じ営業管理ドメインに、マスタの顧客とトランザクションの受注をまとめられます。

2.2 ドメインの作成と、モデルの所属を分けて設定する

1. ドメインを作成します。例えば、IDをsales、名前を「営業管理」とする分類を追加します。この段階では、既存モデルの所属は変更しません。
2. 対象モデルをドメインへ紐づけます。例えば、顧客モデルと受注モデルの所属ドメインにsalesを指定します。ドメインを作るだけで、名前の似たモデルが自動で所属するわけではありません。

ドメインIDは分類を指す安定した識別子、名前は人が読む表示名です。IDは小文字で始め、小文字の英字・数字・アンダースコア・ハイフンを使い、64文字以内にします。同じIDを重複して定義しません。

2.3 所属を指定しない場合と、システムモデルの扱い

各モデルは、定義を読み込んで補完した後に、必ず1つのドメインへ所属します。複数のドメインへ同時に所属させる設定ではありません。

standardとsystemは組み込みの予約IDです。独自に追加しなくても用意されます。業務モデルをsystemへ移したり、システムモデルを営業管理などのドメインへ移したりしません。所属先には、定義済みのドメインIDを指定します。

2.4 分類とアプリケーションの機能を分けて考える

ドメインの追加や所属の変更だけでは、生成コード、DBのテーブルや列、API、権限、メニューの並び、データ移送、アプリケーションの動作は変わりません。ドメインごとに別のサーバーへ配置されることもありません。

例えば受注を営業管理へ紐づけても、営業担当者だけが受注を参照できる設定にはなりません。操作権限は認証と認可、画面への入口はメニューとして別に指定します。分類の変更後は、ドメインIDの重複や所属先の参照切れがないことを設計情報の検証で確認します。

3. AIへの指示例

まず分類を作成し、次に対象モデルを紐づけます。次の2つの指示は、作業の範囲を分けて依頼する例です。

ドメインを作成する

最小限の指示例

モデルを分類するために「営業管理」ドメインを作成してください。既存モデルの所属はまだ変更しないでください。

AIはドメインIDや定義の配置先を、既存の命名・ファイル構成から類推して補います。短い指示だけで、次の詳細例と同じIDや配置先になるとは限りません。

より詳細な指示例

Wagby11のguideと必要なreferenceを確認し、モデルの分類用ドメインを追加してください。
・ドメインIDはsales、名前は「営業管理」にしてください。
・既存のルート定義とrootdefsを確認し、同じIDがあれば新たに重複定義せず、内容を説明してください。
・自動読み込みの分割構成ではdesigner/repository/rootdefs/business-domains.yamlへ追加してください。読み込み方式が異なる場合は、その構成に合う配置先を確認してください。
・今回はドメインの作成だけを行い、モデルの追加や既存モデルの所属変更は行わないでください。
・既存のドメイン、ロール、その他の定義を保持してください。
設計情報を検証し、追加したID・名前・配置先と検証結果を説明してください。

モデルを特定のドメインへ紐づける

最小限の指示例

既存の顧客モデルと受注モデルを「営業管理」ドメインへ紐づけてください。

AIは対象モデルとドメインIDを、既存の表示名・英語識別名・ドメイン定義から判断します。同名のモデルや分類がある場合、あるいは分類がまだない場合は、対象を確認する必要があります。英語識別名とIDを指定すると、紐づけ先を明確にできます。この短い指示だけで、次の詳細例と同じ対象が選ばれるとは限りません。

より詳細な指示例

既存モデルの所属ドメインだけを変更してください。
・ドメインID sales（営業管理）が定義済みであることを確認してください。未定義なら変更せず、確認事項として示してください。
・顧客モデルCustomerと受注モデルSalesOrderのentity.domainをsalesにしてください。
・変更前の所属を確認し、別のドメインから移る場合も変更内容を説明してください。
・他のモデルと、システムモデルの所属は変更しないでください。
・モデルの表示名、英語識別名、migration_id、項目、DB物理名、権限、メニュー、既存データを保持してください。
設計情報を検証し、対象モデルの変更前・変更後のドメインと検証結果を示してください。

4. 編集されるAppSchemaの例

利用者は、分類名と所属させたいモデルをAIへ伝えられます。以下は、その指示で編集する定義の参考例です。構文を覚える必要はありません。

ドメインの定義

自動読み込みの分割構成では、designer/repository/rootdefs/business-domains.yamlに追加できます。既存の定義と重複させません。

domains:
  - id: sales
    name: 営業管理
  - id: accounting
    name: 会計管理

上の例は営業管理と会計管理を用意する場合です。営業管理だけが必要ならsalesの定義だけを追加します。明示参照のみで管理する構成ではrootdefsを自動で読み込まないため、ルートのdesigner/repository/appschema.yamlにdomainsを記述します。

モデルの所属ドメイン

designer/repository/appschema/SalesOrder.yamlの抜粋です。entity.domainにドメインの表示名ではなく、IDのsalesを指定します。

entity:
  name: 受注
  name_en: SalesOrder
  type: T
  domain: sales
  # 既存の項目などの定義は保持

顧客モデルも同じ分類へ紐づける場合は、顧客モデルのentity.domainにもsalesを指定します。ドメイン定義とモデルの所属は、それぞれ別の設定です。

5. 参考資料

guide：モデルを作成する

designer/docs/appschema/html/guide/03-model/01-create-model.html

reference：AppSchema全体構成

designer/docs/appschema/html/reference/02-root-schema.html

reference：entity

designer/docs/appschema/html/reference/06-entity.html