mcpField
A
architecture-design

architecture-design

github.com/dauquangthanh開発1745 回インストール40 週間前に更新
リポジトリ

architecture-design について

architecture-designは、ソフトウェアシステムを計画する開発者やチーム向けのスキルです。要件分析から構成や技術の選定まで支援し、図、意思決定記録、実装計画を作成します。

主な機能

  1. 01要件分析とアーキテクチャ計画
  2. 02システム構成とアーキテクチャ様式
  3. 03技術スタックの評価
  4. 04統合とレジリエンスのパターン
  5. 05Mermaid図とADR
  6. 06仕様書と移行ロードマップ

活用シーン

  1. 01機能・非機能要件に基づく設計
  2. 02モノリス、マイクロサービス、サーバーレスの比較
  3. 03C4図によるシステム構造の記録
  4. 04技術選定と移行手順の記録

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/dauquangthanh/hanoi-rainbow --skill architecture-design

インストール後、Claude Code で/architecture-designを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
adr-template.md
architecture-design-process.md
architecture-patterns.md
best-practices.md
common-anti-patterns-to-avoid.md
design-considerations.md
examples.md
migration-patterns.md
resources-and-references.md
technology-stack-guide.md

詳細

アーキテクチャ設計

概要

このスキルを使用すると、システムコンポーネント、テクノロジースタック、統合パターン、スケーラビリティ戦略、デプロイモデルを含む包括的なソフトウェアソリューションのアーキテクチャを設計できます。

主な機能

有効にすると、このスキルでは次のことができます。

  1. 要件分析とアーキテクチャ計画

    • 機能要件と非機能要件を分析する
    • アーキテクチャ上の主要な要因（スケーラビリティ、セキュリティ、パフォーマンス）を特定する
    • システムの境界と制約を定義する
    • アーキテクチャの目標と成功基準を設定する

  2. システムアーキテクチャ設計

    • 階層型／多層アーキテクチャを設計する
    • マイクロサービスとドメイン駆動設計を作成する
    • イベント駆動型システムとメッセージベースのシステムを設計する
    • サーバーレスおよびクラウドネイティブアーキテクチャを計画する
    • モノリシック、モジュラーモノリシック、または分散システムを設計する

  3. テクノロジースタックの選定

    • プログラミング言語とフレームワークを評価し、選定理由を示す
    • 根拠に基づいてデータベース（SQL、NoSQL、時系列、グラフ）を選定する
    • ミドルウェアと統合プラットフォーム（メッセージキュー、API ゲートウェイ）を選ぶ
    • インフラストラクチャとクラウドプラットフォームを選定する（ベンダーロックインを評価）
    • CI/CD と DevOps のツールを推奨する
    • 検討した代替案とともに、ADR に技術的な決定を記録する
    • 新しいテクノロジーに必要なチームのスキルとトレーニングを評価する

  4. アーキテクチャパターンとベストプラクティス

    • デザインパターン（MVC、MVVM、クリーンアーキテクチャ、ヘキサゴナルアーキテクチャ）を適用する
    • 統合パターン（REST、GraphQL、gRPC、メッセージキュー）を実装する
    • スケーラビリティを考慮して設計する（水平／垂直スケーリング、キャッシュ、CDN）
    • セキュリティパターン（OAuth、JWT、ゼロトラスト）を実装する
    • レジリエンスパターン（サーキットブレーカー、リトライ、バルクヘッド）を適用する

  5. ドキュメントと成果物

    • C4 モデル図を Mermaid 形式で作成する（コンテキスト、コンテナー、コンポーネント、コード）
    • Mermaid 図（クラス図、シーケンス図、デプロイ図）を生成する
    • アーキテクチャ決定記録（ADR）を作成する
    • 技術仕様書と API コントラクトを作成する
    • 実装ロードマップと移行計画を作成する

アーキテクチャ設計ワークフロー

次の体系的なプロセスに従います。

ステップ 1：調査と要件の把握

  1. 要件を収集する

    • 機能要件（機能、ユースケース）
    • 非機能要件（パフォーマンス、スケーラビリティ、セキュリティ）
    • ビジネス上の制約（予算、スケジュール、コンプライアンス）
    • 技術的な制約（既存システム、チームのスキル）

  2. アーキテクチャ上の主要な要因を分析する

    • パフォーマンス：レイテンシー、スループットの目標
    • スケーラビリティ：ユーザー数の増加、データ量の予測
    • 可用性：稼働率 SLA、災害復旧の要件
    • セキュリティ：認証、認可、コンプライアンス要件
    • 保守性：テスト容易性、モジュール性の目標

  3. システムのコンテキストを定義する

    • ステークホルダーとそのニーズを特定する
    • 外部システムと依存関係を整理する
    • システムの境界を定義する
    • 統合ポイントを特定する
ステップ 2：アーキテクチャ設計
  1. アーキテクチャスタイルを選択する

要件と制約に基づいて選択します。

モノリシック

  • 使用場面：シンプルなアプリケーション、MVP、小規模なチーム、厳しい納期
  • メリット：デプロイがシンプル、整合性が高い、ネットワークのオーバーヘッドがない
  • トレードオフ：スケーリングの制限、テクノロジーへのロックイン

モジュラーモノリシック

  • 使用場面：中程度の複雑さ、明確なドメイン境界
  • メリット：構成の改善、ある程度の分離、インフラストラクチャの共有
  • トレードオフ：デプロイは依然として単一、独立したスケーリングに制限がある

マイクロサービス

  • 使用場面：大規模、複数のチーム、異なる技術スタック
  • メリット：独立したスケーリング／デプロイ、テクノロジーの柔軟性
  • トレードオフ：分散システムの複雑さ、ネットワークのオーバーヘッド、結果整合性

サーバーレス

  • 使用場面：イベント駆動型、負荷が変動する場合、迅速な開発
  • メリット：自動スケーリング、従量課金、インフラストラクチャの管理が不要
  • トレードオフ：コールドスタート、ベンダーロックイン、デバッグの複雑さ

イベント駆動型

  • 使用場面：リアルタイム処理、疎結合、高スループット
  • メリット：スケーラビリティ、柔軟性、非同期処理
  • トレードオフ：複雑さ、結果整合性、デバッグの難しさ
  1. システムコンポーネントを設計する

主要なレイヤーとコンポーネントを定義します。

┌─────────────────────────────────┐
│   Presentation Layer            │  UI, Controllers, APIs
├─────────────────────────────────┤
│   Application Layer             │  Use Cases, Orchestration
├─────────────────────────────────┤
│   Domain Layer                  │  Business Logic, Entities
├─────────────────────────────────┤
│   Data Layer                    │  Databases, Caches
├─────────────────────────────────┤
│   Infrastructure Layer          │  External APIs, Services
└─────────────────────────────────┘

  1. データアーキテクチャを定義する

    • データモデルとスキーマを設計する
    • データベースの種類を選択する（リレーショナル、ドキュメント、グラフ、時系列）
    • データのパーティショニングとシャーディングの戦略を計画する
    • キャッシュレイヤーを設計する（Redis、Memcached）
    • データフローと ETL プロセスを定義する

  2. 統合ポイントを設計する

    • API 設計（REST、GraphQL、gRPC）
    • メッセージキュー（Kafka、RabbitMQ、SQS）
    • イベントストリーミングアーキテクチャ
    • 認証と認可のフロー
    • レート制限とスロットリングの戦略
ステップ 3：アーキテクチャを文書化する
  1. アーキテクチャ図を作成する

包括的なドキュメントを作成するために、C4 モデルを Mermaid 形式で使用します。

  • コンテキスト：ユーザーや外部システムを含む環境内でのシステム（Mermaid C4Context を使用）
  • コンテナー：高レベルのテクノロジー選択と通信（Mermaid C4Container を使用）
  • コンポーネント：コンテナーの内部構造（Mermaid C4Component を使用）
  • コード：複雑なコンポーネントのクラス図（Mermaid classDiagram を使用）

すべての図に Mermaid 構文を使用すると、バージョン管理や Markdown でのレンダリングが容易になります。

  1. アーキテクチャ決定記録（ADR）を作成する

構造化された ADR を使用して、重要な決定をすべて文書化します。

# ADR-001: [Decision Title]

## Status
Proposed | Accepted | Deprecated | Superseded

## Context
[Problem and constraints requiring decision]

## Decision
[Chosen solution and approach]

## Consequences
[Benefits and trade-offs]

完全版 ADR テンプレート：例を含む完全な構成については、adr-template.md を参照してください。

  1. 技術仕様を作成する
    • システムの概要と目標
    • コンポーネントの説明と責任
    • API コントラクトとインターフェース
    • データモデルとスキーマ
    • セキュリティおよびコンプライアンス対策
    • デプロイと運用のガイドライン
ステップ 4：検証とレビュー

  1. 品質特性の評価

    • パフォーマンス：応答時間、スループット
    • スケーラビリティ：水平／垂直スケーリングの能力
    • 可用性：フォールトトレランス、災害復旧
    • セキュリティ：認証、認可、暗号化
    • 保守性：コードの構成、テストのしやすさ
    • コスト：インフラストラクチャおよび運用の費用

  2. 設計検証チェックリスト

アーキテクチャがレビュー可能な状態であることを確認します。

  • すべての機能要件と非機能要件に対応している
  • アーキテクチャスタイルの選択理由が説明され、トレードオフが文書化されている
  • スケーラビリティ戦略が定義されている（水平／垂直、容量計画）
  • セキュリティ対策が実装されている（認証、認可、暗号化）
  • データアーキテクチャが検証されている（ストレージ、一貫性、レプリケーション）
  • 統合パターンが指定されている（同期／非同期、API、イベント）
  • 監視とオブザーバビリティが計画されている（メトリクス、ログ、トレース、アラート）
  • 災害復旧とバックアップの戦略が文書化されている（RPO／RTO）
  • コスト見積もりが提示されている（インフラストラクチャ、運用、スケーリング）
  • 主要な決定について、アーキテクチャ決定記録（ADR）が作成されている

参考ファイル

特定のニーズに応じて、参考ファイルを読み込みます。

  • アーキテクチャ設計プロセス：次の場合は architecture-design-process.md を参照してください。

    • 複雑なアーキテクチャについて、詳細なステップごとのガイダンスが必要な場合
    • 各フェーズを体系的に進める場合
    • 包括的なチェックリストや考慮事項が必要な場合

  • アーキテクチャパターン：次の場合は architecture-patterns.md を参照してください。

    • メリットとトレードオフを含む、詳細なパターンの説明が必要な場合
    • 複数のアーキテクチャスタイルを比較する場合
    • 特定のパターンの実装例を探している場合

  • テクノロジースタックガイド：次の場合は technology-stack-guide.md を参照してください。

    • 特定のテクノロジーやフレームワークを評価する場合
    • データベース、言語、クラウドプラットフォームについて推奨事項が必要な場合
    • 特定の要件に応じて技術的な選択肢を比較する場合

  • ベストプラクティス：次の場合は best-practices.md を参照してください。

    • 設計原則やガイドラインが必要な場合
    • API 設計標準を探している場合
    • セキュリティや運用に関するベストプラクティスが必要な場合

  • 設計上の考慮事項：次の場合は design-considerations.md を参照してください。

    • 品質特性（パフォーマンス、スケーラビリティ、セキュリティ）を評価する場合
    • 特定のアーキテクチャ上の課題についてガイダンスが必要な場合
    • オブザーバビリティ、レジリエンス、コスト最適化を計画する場合

  • よくあるアンチパターン：次の場合は common-anti-patterns-to-avoid.md を参照してください。

    • 既存のアーキテクチャの問題点をレビューする場合
    • 設計上の決定を検証する場合
    • 避けるべきことの例が必要な場合

  • 移行パターン：次の場合は migration-patterns.md を参照してください。

    • レガシーアプリケーションをモダナイズする場合
    • 移行戦略を計画する場合
    • 段階的な移行やストラングラーフィグアプローチのパターンが必要な場合

  • 例：次の場合は examples.md を参照してください。

    • よくあるシナリオについて、完全なアーキテクチャ例が必要な場合
    • 実際の参考実装を探している場合
    • パターンが実際にどのように適用されるか確認したい場合

  • リソースと参考資料：次の場合は resources-and-references.md を参照してください。

    • 外部ドキュメントへのリンクが必要な場合
    • 追加の学習リソースを探している場合
    • 仕様や標準の参考資料が必要な場合

出力形式

明確で包括的なアーキテクチャドキュメントを作成します。

  1. アーキテクチャの概要

    • システムの目的と範囲
    • 主要なアーキテクチャ上の決定とその根拠
    • 高レベルのコンポーネント図

  2. 詳細設計

    • コンポーネントの説明と責務
    • データモデルとスキーマ
    • API 仕様
    • 統合パターン

  3. 図（すべて Mermaid 形式）

    • C4 コンテキスト図（Mermaid C4Context）
    • C4 コンテナー図（Mermaid C4Container）
    • 主要なフローのシーケンス図（Mermaid sequenceDiagram）
    • デプロイメント図（Mermaid flowchart または C4Deployment）

  4. 実装ロードマップ

    • マイルストーンを含むフェーズの内訳
    • 依存関係と実施順序
    • 必要なリソース
    • リスク軽減策

  5. アーキテクチャ決定記録

    • 重要な決定をすべて記録します
    • 背景、代替案、トレードオフを含めます

コメント

Markdown 対応