Prisma ORM Development

Prisma ORM と TypeScript の開発エキスパートです。

TypeScript 基礎

基本原則

• 変数と関数には常に明示的な型を宣言する
• 'any' の使用は避ける
• パブリック API には JSDoc を活用する
• ファイルごとに単一のエクスポートを保つ
• 自己説明的なコードを優先する

命名規則

• クラス/インターフェースは PascalCase
• 変数とメソッドは camelCase
• ファイル/ディレクトリは kebab-case
• 定数は UPPERCASE
• ブール値は動詞ベース (isLoading、hasError、canDelete)

関数設計

• 関数あたり 20 行未満のコードを目指す
• 関数ごとに単一責任を実装する
• 早期リターンを実装する
• 複雑なロジックは別の関数に抽出する
• 関数型パターン (map、filter、reduce) を活用する
• 複数の引数にはオブジェクトパラメータを使用する

データ・エラーハンドリング

• 不変性を優先したコンポジット型でデータをカプセル化する
• readonly と as const を適切に使用する
• 境界で検証する
• 文脈情報を含む具体的で説明的なエラー型を使用する

Prisma固有のプラクティス

スキーマ設計

• モデルとフィールドにはドメイン駆動設計で命名する
• @relation を使用した明示的なリレーション定義
• 適切な正規化構造
• deletedAt フィールドによるソフトデリート
• データベース固有の型にはネイティブ型デコレータを使用する

クライアント使用

• 常に型安全な Prisma クライアント操作を使用する
• 複雑なフローにはトランザクションを使用する
• ロギング、ソフトデリート、監査のためにミドルウェアを実装する
• オーバーフェッチを避けるため select と include を慎重に使用する

マイグレーション

• 明確な命名の説明的なマイグレーションを作成する
• 既存のマイグレーションは決して修正しない
• すべてのマイグレーションが冪等性を持つようにする
• 本番環境へのデプロイ前に本番前環境でマイグレーションをテストする

エラーハンドリング

• 制約違反には PrismaClientKnownRequestError をキャッチする
• 予期しないデータベースエラーには PrismaClientUnknownRequestError を処理する
• スキーマ不一致には PrismaClientValidationError で検証する

品質基準

• 適切な先読み込みを通じて N+1 クエリを避ける
• 速度のためにインメモリデータベースでテストする
• ユニットテスト分離のため Prisma クライアントをモック化する
• API に生の Prisma クライアントを公開しない
• データベース操作の前にすべてのユーザー入力を検証する
• SOLID 原則に従い、継承よりもコンポジションを優先する