yodogawa 2.1.3 → 2.2.0

package/templates/project/04-design/07-architecture.md

@@ -1,183 +1,183 @@
-# アーキテクチャ設計
-
-<!--
-何を書くか: システム全体の構造、採用アーキテクチャパターン、重要な設計決定（ADR）
-
-目的:
-  - システム全体の見通しを向上
-  - コンポーネント間の関係を明確化
-  - アーキテクチャ決定の記録と共有
-
-重要性:
-  - 高レベルなアーキテクチャの全体像を把握
-  - 詳細な実装仕様（スペック、パフォーマンス数値）はコードとインフラコードで管理
-
-記載のポイント:
-  - システムアーキテクチャ図で視覚的に表現
-  - 採用したアーキテクチャパターンとその理由
-  - 重要な技術的決定事項（ADR）
-
-更新頻度:
-  - プロジェクト初期にアーキテクチャ設計を作成
-  - アーキテクチャ変更時に更新
-  - 重要な技術的決定時に ADR を追加
--->
-
----
-
-## システムアーキテクチャ図
-
-<!--
-Mermaid を使用してシステム全体の構造を可視化
-
-記載のベストプラクティス:
-  1. 主要なコンポーネントとその関係を記載
-  2. データフローを矢印で表現
-  3. 外部システムとの連携も記載
-  4. レイヤーごとに色分けまたはグループ化
-  5. 複雑な場合は複数の図に分割（全体図、詳細図）
-
-よくあるコンポーネント:
-  - クライアント層: Webブラウザ、モバイルアプリ
-  - プレゼンテーション層: フロントエンド（React, Vue）
-  - API層: REST API, GraphQL
-  - ビジネスロジック層: サービス、ドメインモデル
-  - データアクセス層: ORM、リポジトリ
-  - データストア層: RDBMS, NoSQL, キャッシュ
-  - 外部サービス: 決済API、メール送信、認証サービス
-  - インフラ: ロードバランサー、CDN、キューシステム
-
-Mermaid の記法:
-  - graph TD: 上から下へのフロー
-  - graph LR: 左から右へのフロー
-  - subgraph でグループ化
-  - []: 四角、(): 丸角四角、{}: ひし形、[()]: スタジアム型、[[]]: サブルーチン、[()]: 円柱
--->
-
-```mermaid
-graph TB
-    subgraph "クライアント層"
-        Web[Webブラウザ]
-        Mobile[モバイルアプリ]
-    end
-
-    subgraph "CDN層"
-        CDN[CloudFront CDN]
-    end
-
-    subgraph "ロードバランシング層"
-        LB[Application Load Balancer]
-    end
-
-    subgraph "アプリケーション層"
-        API1[APIサーバー 1<br/>Node.js + Express]
-        API2[APIサーバー 2<br/>Node.js + Express]
-    end
-
-    subgraph "キャッシュ層"
-        Cache[(Redis)]
-    end
-
-    subgraph "データ層"
-        DB[(PostgreSQL<br/>Primary)]
-        DBRead[(PostgreSQL<br/>Read Replica)]
-    end
-
-    subgraph "外部サービス"
-        Auth[認証サービス<br/>Auth0]
-        Payment[決済サービス<br/>Stripe]
-        Email[メール送信<br/>SendGrid]
-    end
-
-    subgraph "ストレージ"
-        S3[Object Storage<br/>Amazon S3]
-    end
-
-    Web --> CDN
-    Mobile --> CDN
-    CDN --> LB
-    LB --> API1
-    LB --> API2
-
-    API1 --> Cache
-    API2 --> Cache
-    API1 --> DB
-    API2 --> DB
-    API1 --> DBRead
-    API2 --> DBRead
-
-    API1 --> Auth
-    API2 --> Auth
-    API1 --> Payment
-    API2 --> Payment
-    API1 --> Email
-    API2 --> Email
-
-    API1 --> S3
-    API2 --> S3
-```
-
-**補足**:
-<!-- 例:
-- クライアントからのリクエストは CDN を経由してキャッシュ可能な静的コンテンツを配信
-- API層は水平スケール可能（オートスケーリング）
-- データベースは Primary/Replica 構成で読み取り負荷を分散
-- Redis でセッション管理とキャッシュを実現
-- 外部サービスとの連携は API Gateway 経由で統一
--->
-
----
-
-## 採用アーキテクチャパターン
-
-<!--
-採用したアーキテクチャパターンとその理由を簡潔に記載
-
-よくあるアーキテクチャパターン:
-  - Layered Architecture: プレゼンテーション層 → ビジネスロジック層 → データアクセス層
-  - Clean Architecture: ドメイン中心、依存性逆転
-  - Microservices: サービスごとに独立したデプロイ
-  - Event-Driven: 非同期処理、疎結合
-
-記載すべき内容:
-  - 採用パターン名
-  - 選定理由（なぜこのパターンが適しているか）
-  - 適用範囲
--->
-
-| 項目 | 内容 |
-|------|------|
-| **採用パターン** | <!-- 例: Layered Architecture（レイヤードアーキテクチャ） --> |
-| **選定理由** | <!-- 例: チームサイズが小規模なため、シンプルで運用コストの低いアーキテクチャを選択 --> |
-| **適用範囲** | <!-- 例: バックエンド全体 --> |
-
----
-
-## ADR（Architecture Decision Record）
-
-<!--
-重要なアーキテクチャ決定を記録
-
-ADR とは:
-  - アーキテクチャに関する重要な決定を記録
-  - 「なぜその決定をしたか」の背景を残す
-  - 将来的な見直しや移行の判断材料
-
-記載すべき内容:
-  - 決定事項: 何を決めたか
-  - 背景: なぜその決定が必要だったか
-  - 代替案: 他の選択肢
-  - 影響: その決定による影響
-  - 決定日: いつ決定したか
-
-よくある決定事項:
-  - データベースの選択
-  - キャッシュ戦略
-  - 認証方式
-  - デプロイ戦略
--->
-
-| 決定事項 | 背景 | 代替案 | 影響 | 決定日 |
-|---------|------|--------|------|--------|
-| <!-- 例: PostgreSQL を採用 --> | <!-- 例: ACID準拠のトランザクションが必要 --> | <!-- 例: MySQL, MongoDB --> | <!-- 例: データ整合性が高い --> | <!-- 例: 2024-01-05 --> |
-| <!-- 例: Redis をセッション管理に使用 --> | <!-- 例: ステートレスな API サーバーを実現 --> | <!-- 例: DB保存, JWT のみ --> | <!-- 例: セッション管理が高速 --> | <!-- 例: 2024-01-10 --> |
+# アーキテクチャ設計
+
+<!--
+何を書くか: システム全体の構造、採用アーキテクチャパターン、重要な設計決定（ADR）
+
+目的:
+  - システム全体の見通しを向上
+  - コンポーネント間の関係を明確化
+  - アーキテクチャ決定の記録と共有
+
+重要性:
+  - 高レベルなアーキテクチャの全体像を把握
+  - 詳細な実装仕様（スペック、パフォーマンス数値）はコードとインフラコードで管理
+
+記載のポイント:
+  - システムアーキテクチャ図で視覚的に表現
+  - 採用したアーキテクチャパターンとその理由
+  - 重要な技術的決定事項（ADR）
+
+更新頻度:
+  - プロジェクト初期にアーキテクチャ設計を作成
+  - アーキテクチャ変更時に更新
+  - 重要な技術的決定時に ADR を追加
+-->
+
+---
+
+## システムアーキテクチャ図
+
+<!--
+Mermaid を使用してシステム全体の構造を可視化
+
+記載のベストプラクティス:
+  1. 主要なコンポーネントとその関係を記載
+  2. データフローを矢印で表現
+  3. 外部システムとの連携も記載
+  4. レイヤーごとに色分けまたはグループ化
+  5. 複雑な場合は複数の図に分割（全体図、詳細図）
+
+よくあるコンポーネント:
+  - クライアント層: Webブラウザ、モバイルアプリ
+  - プレゼンテーション層: フロントエンド（React, Vue）
+  - API層: REST API, GraphQL
+  - ビジネスロジック層: サービス、ドメインモデル
+  - データアクセス層: ORM、リポジトリ
+  - データストア層: RDBMS, NoSQL, キャッシュ
+  - 外部サービス: 決済API、メール送信、認証サービス
+  - インフラ: ロードバランサー、CDN、キューシステム
+
+Mermaid の記法:
+  - graph TD: 上から下へのフロー
+  - graph LR: 左から右へのフロー
+  - subgraph でグループ化
+  - []: 四角、(): 丸角四角、{}: ひし形、[()]: スタジアム型、[[]]: サブルーチン、[()]: 円柱
+-->
+
+```mermaid
+graph TB
+    subgraph "クライアント層"
+        Web[Webブラウザ]
+        Mobile[モバイルアプリ]
+    end
+
+    subgraph "CDN層"
+        CDN[CloudFront CDN]
+    end
+
+    subgraph "ロードバランシング層"
+        LB[Application Load Balancer]
+    end
+
+    subgraph "アプリケーション層"
+        API1[APIサーバー 1<br/>Node.js + Express]
+        API2[APIサーバー 2<br/>Node.js + Express]
+    end
+
+    subgraph "キャッシュ層"
+        Cache[(Redis)]
+    end
+
+    subgraph "データ層"
+        DB[(PostgreSQL<br/>Primary)]
+        DBRead[(PostgreSQL<br/>Read Replica)]
+    end
+
+    subgraph "外部サービス"
+        Auth[認証サービス<br/>Auth0]
+        Payment[決済サービス<br/>Stripe]
+        Email[メール送信<br/>SendGrid]
+    end
+
+    subgraph "ストレージ"
+        S3[Object Storage<br/>Amazon S3]
+    end
+
+    Web --> CDN
+    Mobile --> CDN
+    CDN --> LB
+    LB --> API1
+    LB --> API2
+
+    API1 --> Cache
+    API2 --> Cache
+    API1 --> DB
+    API2 --> DB
+    API1 --> DBRead
+    API2 --> DBRead
+
+    API1 --> Auth
+    API2 --> Auth
+    API1 --> Payment
+    API2 --> Payment
+    API1 --> Email
+    API2 --> Email
+
+    API1 --> S3
+    API2 --> S3
+```
+
+**補足**:
+<!-- 例:
+- クライアントからのリクエストは CDN を経由してキャッシュ可能な静的コンテンツを配信
+- API層は水平スケール可能（オートスケーリング）
+- データベースは Primary/Replica 構成で読み取り負荷を分散
+- Redis でセッション管理とキャッシュを実現
+- 外部サービスとの連携は API Gateway 経由で統一
+-->
+
+---
+
+## 採用アーキテクチャパターン
+
+<!--
+採用したアーキテクチャパターンとその理由を簡潔に記載
+
+よくあるアーキテクチャパターン:
+  - Layered Architecture: プレゼンテーション層 → ビジネスロジック層 → データアクセス層
+  - Clean Architecture: ドメイン中心、依存性逆転
+  - Microservices: サービスごとに独立したデプロイ
+  - Event-Driven: 非同期処理、疎結合
+
+記載すべき内容:
+  - 採用パターン名
+  - 選定理由（なぜこのパターンが適しているか）
+  - 適用範囲
+-->
+
+| 項目 | 内容 |
+|------|------|
+| **採用パターン** | <!-- 例: Layered Architecture（レイヤードアーキテクチャ） --> |
+| **選定理由** | <!-- 例: チームサイズが小規模なため、シンプルで運用コストの低いアーキテクチャを選択 --> |
+| **適用範囲** | <!-- 例: バックエンド全体 --> |
+
+---
+
+## ADR（Architecture Decision Record）
+
+<!--
+重要なアーキテクチャ決定を記録
+
+ADR とは:
+  - アーキテクチャに関する重要な決定を記録
+  - 「なぜその決定をしたか」の背景を残す
+  - 将来的な見直しや移行の判断材料
+
+記載すべき内容:
+  - 決定事項: 何を決めたか
+  - 背景: なぜその決定が必要だったか
+  - 代替案: 他の選択肢
+  - 影響: その決定による影響
+  - 決定日: いつ決定したか
+
+よくある決定事項:
+  - データベースの選択
+  - キャッシュ戦略
+  - 認証方式
+  - デプロイ戦略
+-->
+
+| 決定事項 | 背景 | 代替案 | 影響 | 決定日 |
+|---------|------|--------|------|--------|
+| <!-- 例: PostgreSQL を採用 --> | <!-- 例: ACID準拠のトランザクションが必要 --> | <!-- 例: MySQL, MongoDB --> | <!-- 例: データ整合性が高い --> | <!-- 例: 2024-01-05 --> |
+| <!-- 例: Redis をセッション管理に使用 --> | <!-- 例: ステートレスな API サーバーを実現 --> | <!-- 例: DB保存, JWT のみ --> | <!-- 例: セッション管理が高速 --> | <!-- 例: 2024-01-10 --> |