Home
Get Started
実践ガイド
外部仕様設計
バッチ処理仕様設計
UAC 仕様設計
データ仕様設計
インフラ設計
移行計画
テスト方針・計画
開発プロセス・規約
アプリケーション共通処理方式
アプリケーション全体で共通的に使用する処理方式を統一し、品質の均一化、保守性の向上、開発効率の向上を実現するための標準仕様を定義します。
🎯 概要
- 目的: アプリケーション全体で共通的に使用する処理方式を統一し、品質の均一化、保守性の向上、開発効率の向上を実現する
- スコープ: ログ出力、例外処理、セッション管理、DBアクセス、トランザクション制御、バリデーション、通知など、アプリケーション横断的に使用する処理をカバーする。個別の業務処理ロジックは対象外
- 推奨する実施タイミング: 通常、システムアーキテクチャ設計後、個別機能設計の前に実施する
- 関連するステークホルダー: アプリケーションアーキテクト、開発リーダー、開発者、運用チーム
📥 重要な前提知識・インプット
- 前提知識: アプリケーションフレームワークの仕組み、デザインパターン(レイヤードアーキテクチャ、DIなど)、Webアプリケーションの基本的な仕組み
- インプット: システムアーキテクチャ設計書、採用技術スタック、非機能要件(性能、可用性、セキュリティ)、運用要件
📄 成果物の定義
- ドキュメントテンプレート: 📄
[テンプレ]アプリケーション共通処理方式
- 必須要素: ログ出力仕様、例外・エラー処理仕様、セッション管理方式、DBアクセス処理方式、トランザクション管理仕様、同時実行制御方式、バリデーション方式、通知方式
✅ 品質基準・レビュー観点
✅ 品質チェックリスト:
| チェック項目 | チェック内容 |
|---|---|
| 処理方式の網羅性 | 必要な共通処理(ログ、例外処理、セッション管理など)が漏れなく定義されている |
| 一貫性の確保 | 全ての処理で一貫したルールとフォーマットが定義されている |
| 実装容易性 | フレームワークやライブラリとの整合性があり、実装しやすい仕様になっている |
| 運用性の考慮 | 障害調査、監視、トラブルシューティングに必要な情報(ログ、エラーコードなど)が十分に設計されている |
| セキュリティ対策 | セキュリティ上のリスク(個人情報漏洩、SQLインジェクションなど)への対策が盛り込まれている |
👁️🗨️ レビュー観点:
- 要件との整合性: 非機能要件(性能・可用性・セキュリティ・運用性)が共通処理方式に反映されているか
- 実装可能性: フレームワークやミドルウェアの機能で実現可能な仕様か
- 開発生産性: 開発者が理解しやすく、コーディングしやすい仕様になっているか
- 保守性: 将来の変更や拡張に対応しやすい設計になっているか
🧪成果物のサンプル
# アプリケーション共通処理方式
本章では、アプリケーション全体で共通的に使用する処理方式を定義します。
各機能実装時は本方式に従うことで、品質の統一と保守性の向上を図ります。
---
## ログ出力仕様
### ログレベル定義
| レベル | 用途 | 出力タイミング |
|--------|------|--------------|
| ERROR | エラー情報 | システムエラー、業務エラー発生時 |
| WARN | 警告情報 | 想定外だが処理継続可能な事象 |
| INFO | 情報ログ | 主要な処理の開始・終了、状態変化 |
| DEBUG | デバッグ情報 | 開発時のデバッグ用詳細情報 |
### ログ出力形式
**JSON形式での構造化ログ:**
```json
{
"timestamp": "2025-11-20T15:30:00.123Z",
"level": "INFO",
"logger": "com.example.service.OrderService",
"message": "注文処理開始",
"trace_id": "trace_abc123",
"span_id": "span_xyz789",
"user_id": "user_12345",
"request_id": "req_abc123",
"context": {
"order_id": "order_98765",
"amount": 15000
}
}
```
### ログ出力項目
**必須項目:**
- タイムスタンプ
- ログレベル
- ロガー名(クラス名)
- メッセージ
- トレースID(分散トレーシング用)
**任意項目:**
- ユーザーID
- リクエストID
- 業務キー(注文ID等)
- コンテキスト情報
### 個人情報のマスキング
**マスキング対象:**
- パスワード: 完全マスキング(`***`)
- メールアドレス: 部分マスキング(`ya***@example.com`)
- クレジットカード番号: 下4桁以外マスキング(`************1234`)
- 電話番号: 中間部マスキング(`090-****-5678`)
### ログローテーション
**設定:**
- ファイルサイズ: 100MB
- 世代管理: 30世代
- 圧縮: gzip圧縮
- 保存期間: 3ヶ月
---
## 例外・エラー処理仕様
### 例外階層構造
```mermaid
graph TD
A[Exception] --> B[ApplicationException<br/>アプリケーション例外]
A --> C[SystemException<br/>システム例外]
B --> D[BusinessException<br/>業務エラー]
B --> E[ValidationException<br/>検証エラー]
C --> F[DatabaseException<br/>DB例外]
C --> G[ExternalApiException<br/>外部API例外]
```
### エラーコード体系
**フォーマット:** `{カテゴリ}{連番}`
| カテゴリ | コード範囲 | 説明 |
|---------|-----------|------|
| AUTH | AUTH-001~099 | 認証・認可エラー |
| VAL | VAL-001~099 | 入力検証エラー |
| BIZ | BIZ-001~099 | 業務エラー |
| DB | DB-001~099 | データベースエラー |
| EXT | EXT-001~099 | 外部連携エラー |
| SYS | SYS-001~099 | システムエラー |
### エラーレスポンス形式
```json
{
"error_code": "VAL-001",
"message": "入力値が不正です",
"details": [
{
"field": "email",
"message": "メールアドレスの形式が正しくありません"
}
],
"timestamp": "2025-11-20T15:30:00Z",
"request_id": "req_abc123"
}
```
### 例外ハンドリングフロー
```mermaid
graph TD
A[処理実行] --> B{例外発生?}
B -->|No| C[正常終了]
B -->|Yes| D{例外種別判定}
D -->|業務エラー| E[エラーログ出力<br/>WARN]
D -->|システムエラー| F[エラーログ出力<br/>ERROR]
E --> G[ユーザーへ<br/>エラーメッセージ表示]
F --> H[管理者へ<br/>アラート通知]
G --> I[エラー画面/<br/>エラーレスポンス]
H --> I
```
### エラーハンドリング方針
**業務エラー:**
- ユーザーに分かりやすいメッセージを表示
- リトライ可能な場合はその旨を通知
- ログレベル: WARN
**システムエラー:**
- 一般的なエラーメッセージを表示(詳細は隠蔽)
- 管理者に即座に通知
- ログレベル: ERROR
---
## セッション管理方式
### セッション実装方式
**採用技術:**
- サーバーサイド: Redisベースのセッションストア
- クライアント: Cookieベースのセッション管理
### セッション設定
**Cookie属性:**
```
Set-Cookie: session_id=abc123xyz789;
Path=/;
HttpOnly;
Secure;
SameSite=Strict;
Max-Age=3600
```
**タイムアウト設定:**
- セッションタイムアウト: 30分(無操作時)
- 絶対タイムアウト: 8時間(ログインからの経過時間)
- タイムアウト前警告: 5分前に通知
### セッション格納データ
**格納項目:**
- ユーザーID
- ロール・権限情報
- 最終アクセス時刻
- ログイン時刻
- CSRF トークン
- 言語設定
**格納禁止項目:**
- パスワード
- クレジットカード情報
- 個人番号
- 機密性の高い個人情報
### セッション同期
**マルチサーバー環境:**
- Redis Clusterによるセッション共有
- スティッキーセッションは使用しない
- セッションデータの一貫性保証
---
## DBアクセス処理方式
### データアクセス層構成
```mermaid
graph LR
A[Controller<br/>制御層] --> B[Service<br/>業務層]
B --> C[Repository<br/>データアクセス層]
C --> D[Entity<br/>エンティティ]
C --> E[Database<br/>データベース]
```
### アクセス方針
**基本方針:**
- レイヤー間の責務分離を徹底
- SQLインジェクション対策(プリペアドステートメント使用)
- N+1問題の回避(適切なJOIN、バッチ処理)
- インデックスの適切な使用
### ORM使用方針
**使用方針:**
- 基本的にORMのクエリビルダーを使用
- 複雑なクエリ・パフォーマンスが重要な処理はネイティブSQL許可
- 動的クエリは専用のビルダーパターンを使用
### コネクションプール設定
**推奨設定:**
- 最小アイドル接続数: 10
- 最大接続数: 50
- コネクションタイムアウト: 30秒
- アイドルタイムアウト: 10分
- 最大ライフタイム: 30分
### クエリパフォーマンス管理
**監視項目:**
- スロークエリの検知(閾値: 1秒以上)
- クエリ実行回数
- コネクションプール使用率
---
## トランザクション管理・スコープ管理仕様
### トランザクション境界
**基本方針:**
- Serviceレイヤーでトランザクション境界を定義
- 1つのユースケース(ユーザー操作)= 1トランザクション
- トランザクションは可能な限り短く保つ
### トランザクション制御フロー
```mermaid
graph TD
A[処理開始] --> B[トランザクション開始]
B --> C{業務処理}
C -->|成功| D[コミット]
C -->|失敗| E[ロールバック]
D --> F[処理完了]
E --> G[エラー処理]
G --> H[ログ記録]
```
### 分離レベル
| レベル | 用途 | 備考 |
|--------|------|------|
| READ_COMMITTED | 通常の参照・更新処理 | デフォルト |
| REPEATABLE_READ | 複数回読み取りで一貫性が必要 | ファントムリード注意 |
| SERIALIZABLE | 厳密な一貫性が必要な処理 | 決済等、パフォーマンス低下注意 |
### トランザクション伝播
| 伝播タイプ | 説明 |
|----------|------|
| REQUIRED | トランザクションがあれば参加、なければ新規作成(デフォルト) |
| REQUIRES_NEW | 常に新しいトランザクションを作成 |
| NESTED | ネストしたトランザクションを作成 |
| SUPPORTS | トランザクションがあれば参加、なくても実行 |
---
## 同時実行制御方式
### 楽観的ロック
**実装方式:**
- バージョン番号による制御
- 更新時にバージョン番号をチェック
- 競合検知時は適切なエラーメッセージを表示
**制御フロー:**
```mermaid
sequenceDiagram
participant User1
participant User2
participant DB
User1->>DB: データ取得(version=1)
User2->>DB: データ取得(version=1)
User1->>DB: 更新(version=1→2)
DB-->>User1: 成功
User2->>DB: 更新(version=1→2)
DB-->>User2: 失敗(version不一致)
User2->>DB: 最新データ再取得
```
**適用対象:**
- 競合発生頻度が低い処理
- ユーザーによるデータ編集
- マスタデータの更新
### 悲観的ロック
**使用場面:**
- 在庫管理等、確実にロックが必要な処理
- 複数レコードの整合性を保証する処理
- 競合発生頻度が高い処理
**ロック範囲:**
- 必要最小限のレコードのみロック
- ロック時間を最短化
- デッドロック回避のためロック順序を統一
### 二重サブミット防止
**トークン方式:**
1. 画面表示時にワンタイムトークンを発行
2. サブミット時にトークンを検証
3. 使用済みトークンは即座に破棄
**実装フロー:**
```mermaid
sequenceDiagram
participant Browser
participant Server
participant TokenStore
Browser->>Server: 画面表示要求
Server->>TokenStore: トークン生成
TokenStore-->>Server: token_abc123
Server-->>Browser: 画面+トークン
Browser->>Server: サブミット(token_abc123)
Server->>TokenStore: トークン検証
alt トークン有効
TokenStore-->>Server: OK
Server->>TokenStore: トークン削除
Server-->>Browser: 処理成功
else トークン無効
TokenStore-->>Server: NG
Server-->>Browser: エラー(二重サブミット)
end
```
**トークン管理:**
- 有効期間: 1時間
- 保存先: Redis
- トークン形式: UUID v4
---
## バリデーション方式
### バリデーション実施箇所
**多層防御アプローチ:**
```mermaid
graph LR
A[クライアント側<br/>バリデーション] --> B[サーバー側<br/>バリデーション]
B --> C[データベース<br/>制約]
```
1. **クライアント側バリデーション**
- 目的: UX向上、即座のフィードバック
- 信頼性: 低(バイパス可能)
2. **サーバー側バリデーション**(必須)
- 目的: セキュリティ、データ整合性
- 信頼性: 高
3. **データベース制約**
- 目的: 最後の砦、データ整合性保証
- 信頼性: 最高
### バリデーションルール
**共通ルール:**
| 項目 | ルール | チェック内容 |
|------|--------|------------|
| 必須チェック | Required | 未入力不可 |
| 型チェック | Type | データ型の妥当性 |
| 桁数チェック | Length | 最小・最大桁数 |
| 形式チェック | Format | 正規表現による形式検証 |
| 範囲チェック | Range | 数値・日付の範囲 |
| 相関チェック | Cross-field | 項目間の整合性 |
**具体的なバリデーション例:**
| 項目 | ルール |
|------|--------|
| メールアドレス | RFC 5322準拠の形式 |
| 電話番号 | 国内形式: `0X0-XXXX-XXXX` |
| 郵便番号 | `XXX-XXXX` 形式 |
| URL | RFC 3986準拠 |
| 日付 | ISO 8601形式 |
### エラーメッセージ
**メッセージ方針:**
- ユーザーにとって分かりやすい表現
- 具体的な修正方法を提示
- セキュリティ情報は漏洩させない
**メッセージ例:**
- ❌ 悪い例: "Validation error in field 'email'"
- ✅ 良い例: "メールアドレスの形式が正しくありません。例: user@example.com"
---
## 通知方式
### 通知チャネル
| チャネル | 用途 | 優先度 | 到達時間 |
|---------|------|--------|---------|
| メール | 重要通知、定期レポート | 高 | 数分以内 |
| SMS | 緊急通知、2要素認証 | 最高 | 即時 |
| プッシュ通知 | リアルタイム情報 | 中 | 即時 |
| Slack/Teams | システムアラート | 高 | 即時 |
| アプリ内通知 | 一般的なお知らせ | 低 | 次回ログイン時 |
### 通知フロー
```mermaid
graph LR
A[通知要求] --> B[メッセージキュー]
B --> C[通知ワーカー]
C --> D{チャネル振り分け}
D --> E[メール送信]
D --> F[SMS送信]
D --> G[プッシュ通知]
E --> H[送信履歴記録]
F --> H
G --> H
```
### 通知テンプレート管理
**テンプレート構成:**
- テンプレートID
- 件名テンプレート
- 本文テンプレート
- プレースホルダー定義
- 多言語対応
### 送信制御
**レート制限:**
- 同一ユーザーへの送信: 10通/時間
- システム全体: 1000通/分
**リトライ制御:**
- 最大リトライ回数: 3回
- リトライ間隔: 指数バックオフ(1分、5分、15分)
- 恒久的エラーはリトライしない(例: 宛先不正)
**送信履歴:**
- 送信日時
- 送信先
- 送信結果(成功/失敗)
- エラー詳細
---
## その他共通処理方式
### ページネーション
**実装方式:**
| 方式 | 用途 | 特徴 |
|------|------|------|
| オフセットベース | 小規模データ、ページ番号指定 | 実装シンプル、大規模データで性能劣化 |
| カーソルベース | 大規模データ、無限スクロール | 高速、ページ番号指定不可 |
**レスポンス形式:**
```json
{
"data": [...],
"pagination": {
"total": 1000,
"page": 1,
"per_page": 20,
"total_pages": 50,
"has_next": true,
"has_prev": false
}
}
```
### ソート機能
**ソート指定:**
- フィールド名とソート順を指定
- 複数フィールドのソート対応
- デフォルトソート順の定義
### フィルタリング
**フィルタ条件:**
- 等価条件(equals)
- 範囲条件(between、greater than、less than)
- 部分一致(like、contains)
- IN条件(複数値指定)
### キャッシュ制御
**キャッシュ戦略:**
```mermaid
graph TD
A[リクエスト] --> B{キャッシュ<br/>存在?}
B -->|Yes| C[キャッシュ返却]
B -->|No| D[DBアクセス]
D --> E[キャッシュ保存]
E --> F[レスポンス返却]
```
**キャッシュ階層:**
1. ブラウザキャッシュ
2. CDNキャッシュ
3. アプリケーションキャッシュ(Redis)
4. DBキャッシュ
**キャッシュキー設計:**
```
{namespace}:{entity}:{id}:{version}
例: app:user:12345:v1
```
**TTL(Time To Live)設定:**
- マスタデータ: 1時間
- ユーザーデータ: 10分
- 一時データ: 5分
### 一括処理
**バッチ処理方針:**
- データ量に応じたチャンク分割
- トランザクションサイズの適切な管理
- 処理状況の可視化
- エラー発生時の部分ロールバック
### 国際化(i18n)・地域化(l10n)対応
**対応項目:**
- 言語切替(日本語、英語等)
- 日時フォーマット
- 数値フォーマット(桁区切り、小数点)
- 通貨表示
**言語判定優先順位:**
1. ユーザー設定
2. Accept-Languageヘッダー
3. デフォルト言語(日本語)
**メッセージ管理:**
- 言語ごとにリソースファイルを用意
- キー: `{カテゴリ}.{項目}`
- プレースホルダーによる動的置換
### ファイルアップロード・ダウンロード
**アップロード制限:**
- 最大ファイルサイズ: 10MB
- 許可ファイル形式: PDF、画像(JPEG、PNG)、Excel等
- ウイルススキャン実施
**ダウンロード制御:**
- ストリーミング方式(大容量ファイル対応)
- Content-Dispositionヘッダーによるファイル名指定
- レート制限
--- 🔄 設計の進め方・プロセス
🏗️ プロセス1: ログ出力仕様の設計
設計対象:
アプリケーション全体で統一したログ出力方式を設計し、障害調査や運用監視に必要な情報を適切に記録する。
具体例:
- ログレベル(ERROR、WARN、INFO、DEBUGなど)の定義と出力タイミング
- ログフォーマット(JSON、テキスト形式)とログ出力項目の決定
- 個人情報のマスキングルールの定義
- ログローテーション、保存期間、保存先の設定
- 分散トレーシング対応(トレースID、スパンIDの付与)
設計原則:
- 構造化ログ: JSON形式などの構造化ログを採用し、ログ分析ツールで解析しやすくする
- トレーサビリティ: 一連の処理を追跡できるよう、リクエストID、トレースIDを全てのログに出力する
- 個人情報保護: パスワード、クレジットカード情報などの機密情報は必ずマスキングする
- 運用性の確保: 障害発生時に迅速に原因を特定できるよう、適切な情報を適切なレベルで出力する
- パフォーマンス考慮: 大量のログ出力がパフォーマンスに影響を与えないよう、非同期ログ出力や適切なレベル設定を行う
文書化の推奨表現:
- ログレベル定義表: 各レベルの用途と出力タイミングを表形式で整理する
- ログフォーマット例: 実際のログ出力例を JSON形式で記載する
- マスキングルール: 個人情報ごとのマスキング方法を明確にする
- ログローテーション設定: ファイルサイズ、世代管理、圧縮方法を具体的に記載する
🏗️ プロセス2: 例外・エラー処理仕様の設計
設計対象:
例外の分類、エラーコード体系、エラーメッセージ、エラーハンドリング方針を設計する。
具体例:
- 例外階層構造(業務エラー、システムエラーなど)の定義
- エラーコード体系(AUTH-001、VAL-001など)の設計
- エラーレスポンスフォーマットの統一
- エラー発生時のログ出力レベルと通知方法の決定
- ユーザーへのエラーメッセージ表示方針
設計原則:
- 例外の分類: 業務エラー、検証エラー、システムエラーなど、例外の種類を明確に分類する
- エラーコードの体系化: カテゴリ別に一意なエラーコードを付与し、エラー内容を識別しやすくする
- ユーザーフレンドリーなメッセージ: ユーザーには分かりやすく、セキュリティ上問題のないメッセージを表示する
- セキュリティ考慮: システムエラーの詳細情報は隠蔽し、管理者のみがアクセスできるようにする
- 適切な通知: システムエラー発生時は管理者に即座に通知し、迅速な対応を可能にする
文書化の推奨表現:
- 例外階層図: 例外クラスの継承関係を図示する
- エラーコード一覧表: カテゴリ、コード範囲、説明を表形式で整理する
- エラーレスポンス例: JSON形式でのエラーレスポンスの具体例を記載する
- エラーハンドリングフロー図: 例外発生からユーザー通知までのフローを図示する
🏗️ プロセス3: セッション管理方式の設計
設計対象:
ユーザーのログイン状態を管理するセッションの実装方式、タイムアウト設定、格納データを設計する。
具体例:
- セッション実装方式(サーバーサイドセッション、JWTトークンなど)の選定
- Cookie属性(HttpOnly、Secure、SameSite)の設定
- セッションタイムアウト(無操作時、絶対タイムアウト)の決定
- セッションに格納するデータと格納禁止データの定義
- マルチサーバー環境でのセッション共有方式の設計
設計原則:
- セキュアな実装: HttpOnly、Secure、SameSite属性を適切に設定し、XSS、CSRF攻撃を防ぐ
- 適切なタイムアウト設定: 利便性とセキュリティのバランスを考慮したタイムアウト時間を設定する
- 機密情報の保護: パスワード、クレジットカード情報などはセッションに格納しない
- スケーラビリティ: マルチサーバー環境でも一貫したセッション管理ができるよう、Redis などの外部ストアを使用する
- セッション同期: スティッキーセッションに依存せず、どのサーバーでもセッション情報にアクセスできるようにする
文書化の推奨表現:
- Cookie属性設定: Set-Cookieヘッダーの具体的な設定値を記載する
- タイムアウト設定表: 各種タイムアウト値とその理由を表形式で整理する
- セッションデータ一覧: 格納する項目と格納禁止項目を明確に区分する
- セッション共有アーキテクチャ図: マルチサーバー環境でのセッション共有の仕組みを図示する
🏗️ プロセス4: DBアクセス・トランザクション管理仕様の設計
設計対象:
データベースへのアクセス方式、トランザクション境界、分離レベル、同時実行制御を設計する。
具体例:
- データアクセス層の構成(Controller、Service、Repositoryの責務分担)
- ORM使用方針(クエリビルダー、ネイティブSQLの使い分け)
- コネクションプール設定(最小接続数、最大接続数、タイムアウト)
- トランザクション境界と伝播方式の定義
- 同時実行制御方式(楽観的ロック、悲観的ロック)の選定
設計原則:
- レイヤーの責務分離: Controller、Service、Repositoryの責務を明確に分離し、保守性を高める
- SQLインジェクション対策: プリペアドステートメントを必須化し、セキュリティを確保する
- パフォーマンス最適化: N+1問題の回避、適切なインデックス使用、スロークエリの監視を行う
- トランザクション最小化: トランザクションは可能な限り短く保ち、デッドロックのリスクを低減する
- 適切な分離レベル: 処理の特性に応じて適切なトランザクション分離レベルを選択する
文書化の推奨表現:
- データアクセス層構成図: Controller、Service、Repository、Entityの関係を図示する
- コネクションプール設定表: 各パラメータの推奨値とその理由を記載する
- トランザクション伝播一覧: 各伝播タイプの説明と使用場面を表形式で整理する
- 同時実行制御フロー図: 楽観的ロック、悲観的ロックのフローをシーケンス図で図示する
🏗️ プロセス5: バリデーション・通知方式の設計
設計対象:
入力値検証のルールと実施箇所、通知チャネルと送信制御を設計する。
具体例:
- バリデーション実施箇所(クライアント側、サーバー側、DB制約)の定義
- バリデーションルール(必須チェック、形式チェック、範囲チェックなど)の設計
- エラーメッセージの表現方針とメッセージ例の作成
- 通知チャネル(メール、SMS、プッシュ通知など)の選定と用途定義
- 通知送信制御(レート制限、リトライ、送信履歴記録)の設計
設計原則:
- 多層防御: クライアント側、サーバー側、DB制約の3層でバリデーションを実施し、データ整合性を保証する
- ユーザーフレンドリーなメッセージ: ユーザーが修正方法を理解できる、分かりやすいエラーメッセージを提供する
- セキュリティ考慮: エラーメッセージからシステムの内部情報が漏洩しないようにする
- 適切なチャネル選択: 通知の重要度と緊急度に応じて適切なチャネルを選択する
- 送信制御: レート制限やリトライ制御により、システムへの負荷やスパム送信を防止する
文書化の推奨表現:
- バリデーション階層図: クライアント側、サーバー側、DB制約の3層を図示する
- バリデーションルール一覧: 各ルールのチェック内容と具体例を表形式で整理する
- 通知チャネル比較表: 各チャネルの用途、優先度、到達時間を比較表で示す
- 通知フロー図: 通知要求から送信履歴記録までのフローを図示する
🚨 よくある失敗と予防策
🚧 実例収集後、追記予定
📚 参考資料・関連リンク
- 参考文献: 『Effective Java』、『リーダブルコード』、Spring Framework公式ドキュメント、各種フレームワークのベストプラクティス
- 関連する他のガイド: システムアーキテクチャ設計ガイド、セキュリティ仕様・方式ガイド、データベース設計ガイド、運用設計ガイド
- ツール・テンプレート: ログ出力設計テンプレート、エラーコード管理表テンプレート、バリデーションルール定義テンプレート
テンプレートサイト: 📄テンプレート集