メインコンテンツまでスキップ

クラスのステレオタイプとパッケージ構成

プロジェクトで扱うクラスの役割(ステレオタイプ)とそれらがどのパッケージに配置されるべきかというルールをAIに伝えることは、一貫性を持ったコードを生成させ、保守性を高めるうえでも重要です。

AIが新しいクラスを作成する際に、プロジェクトの設計思想にもとづいた適切な場所へ適切な責務を持ったクラスを生成することを促すことができます。

注記

本ページの内容は、言語によってはディレクトリ構成内に含めた方が扱いやすいケースもあるでしょう。

以下は、クラスのステレオタイプやパッケージ構成に関するインストラクションファイルの記述例です。

---
applyTo: "**"
---

# クラスのステレオタイプとパッケージ構成

## クラスのステレオタイプ

各パッケージに配置されるクラスの責務(ステレオタイプ)は以下の通りです。

| ステレオタイプ | パッケージ | 責務 |
| :------------- | :----------- | :----------------------------------------------------------------------- |
| Controller | `controller` | HTTPリクエストを受け付け、Serviceクラスに処理を移譲し、処理結果をレスポンスとして返す |
| Request | `request` | HTTPリクエストをマッピングするためのクラス |
| Response | `response` | HTTPレスポンスを表すクラス |
| DTO | `dto` | 業務処理で使用するデータオブジェクト |
| Service | `service` | アプリケーションのビジネスロジックを実装する |
| Mapper | `mapper` | MyBatisの機能を使い、データベースアクセスを行うためのインタフェース |
| Model | `model` | データベースのテーブルと対応するクラス |

## パッケージ構成

各機能単位のパッケージは、ルートを`com.example.myapp.[機能名]`として以下の構成とします。

| パッケージ | 概要 |
| :----------- | :------------------------------------- |
| `controller` | Controllerクラスを配置するパッケージ |
| `request` | Requestクラスを配置するパッケージ |
| `response` | Responseクラスを配置するパッケージ |
| `service` | Serviceクラスを配置するパッケージ |
| `dto` | DTOクラスを配置するパッケージ |
| `mapper` | Mapperインタフェースを配置するパッケージ |
| `model` | Modelクラスを配置するパッケージ |

またプロジェクト内で共通で利用する機能のパッケージは`com.example.myapp.common`をルートとし、以下の構成とします。

| パッケージ | 概要 |
| :----------- | :---------------------------------------------------------------------- |
| `exception` | アプリケーションの例外クラスを配置するパッケージ |
| `mapper` | MyBatis Generatorにより自動生成されたMapperインタフェースを配置するパッケージ |
| `model` | MyBatis Generatorにより自動生成されたModelクラスを配置するパッケージ |
| `security` | Spring Securityの設定を配置するパッケージ |
| `validation` | プロジェクト独自のバリデーション関連のクラスを配置するパッケージ |

このようなインストラクションファイルを、.github/instructions/stereotype.instructions.mdのようなファイル名で作成します。これにより、GitHub Copilotはプロジェクトの論理的な構造をより深く理解し、適切な開発支援ができるようになります。