mcpField
S
software-architecture

software-architecture

github.com/sickn33開発48.7k3.7k 回インストール今日更新
リポジトリ

software-architecture について

software-architectureは、構造とコード品質の向上を目指す開発者向けのスキルです。Clean Architectureとドメイン駆動設計に基づき、コード規約、依存関係の選択、アンチパターンを案内します。

主な機能

  1. 01Clean Architecture と DDD の指針
  2. 02ビジネスロジックとインフラの分離
  3. 03既存ライブラリやサービスの優先評価
  4. 04モジュールの命名と責務境界
  5. 05可読性とコード分割の規則

活用シーン

  1. 01新規プロジェクトの境界設計
  2. 02混在したビジネスロジックの分離
  3. 03独自実装と既存ライブラリの比較
  4. 04コード構造と命名のレビュー

インストール

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

$npx skills add https://github.com/sickn33/agentic-awesome-skills --skill software-architecture

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

詳細

ソフトウェアアーキテクチャ開発スキル

このスキルは、品質重視のソフトウェア開発とアーキテクチャのためのガイダンスを提供します。クリーンアーキテクチャとドメイン駆動設計の原則に基づいています。

コードスタイルのルール

一般的な原則
  • 早期リターンパターン: 可読性を高めるため、ネストした条件分岐よりも、可能な限り常に早期リターンを使用してください
  • 再利用可能な関数やモジュールを作成することで、コードの重複を避けてください
  • 長い（80 行を超えるコードの）コンポーネントや関数は、複数の小さなコンポーネントや関数に分解してください。他で使用できない場合は、同じファイルに保持してください。ただし、ファイルが 200 行を超えるコードになる場合は、複数のファイルに分割する必要があります。
  • 可能な限り、関数宣言ではなくアロー関数を使用してください
ベストプラクティス
ライブラリファーストのアプローチ
  • カスタムコードを書く前に、常に既存のソリューションを検索してください
    • 問題を解決する既存のライブラリがないか npm を確認してください
    • 既存のサービス/SaaS ソリューションを評価してください
    • 一般的な機能についてはサードパーティの API を検討してください
  • 独自のユーティリティやヘルパーを書く代わりに、ライブラリを使用してください。たとえば、独自のリトライロジックを書く代わりに cockatiel を使用してください。
  • カスタムコードが正当化される場合:
    • ドメインに固有のビジネスロジック
    • 特別な要件を持つパフォーマンスクリティカルなパス
    • 外部依存が過剰になる場合
    • 完全な制御が必要なセキュリティに敏感なコード
    • 徹底的に評価した結果、既存のソリューションが要件を満たさない場合
アーキテクチャと設計
  • クリーンアーキテクチャと DDD の原則:
    • ドメイン駆動設計とユビキタス言語に従ってください
    • ドメインエンティティをインフラストラクチャの関心事から分離してください
    • ビジネスロジックをフレームワークから独立させてください
    • ユースケースを明確に定義し、それらを分離して保ってください
  • 命名規則:
    • 汎用的な名前を 避けてください: utils、helpers、common、shared
    • ドメイン固有の名前を 使用してください: OrderCalculator、UserAuthenticator、InvoiceGenerator
    • 境界づけられたコンテキストの命名パターンに従ってください
    • 各モジュールは単一の明確な目的を持つべきです
  • 関心の分離:
    • ビジネスロジックを UI コンポーネントと混在させないでください
    • データベースクエリをコントローラーから排除してください
    • コンテキスト間の明確な境界を維持してください
    • 責任の適切な分離を確保してください
避けるべきアンチパターン
  • NIH（Not Invented Here）症候群:
    • Auth0/Supabase が存在するのに独自の認証を構築しないでください
    • Redux/Zustand を使用せずに独自の状態管理を書かないでください
    • 確立されたライブラリを使用せずに独自のフォームバリデーションを作成しないでください
  • 不適切なアーキテクチャの選択:
    • ビジネスロジックと UI コンポーネントの混在
    • コントローラー内のデータベースクエリ
    • 関心の分離の欠如
  • 汎用的な命名のアンチパターン:
    • 無関係な 50 個の関数を含む utils.js
    • 何でも放り込む場所としての helpers/misc.js
    • 目的が不明確な common/shared.js
  • 覚えておいてください: カスタムコードのすべての行は、メンテナンス、テスト、ドキュメント化が必要な負債です
コード品質
  • 型付き catch ブロックによる適切なエラーハンドリング
  • 複雑なロジックをより小さく再利用可能な関数に分割してください
  • 深いネストを避けてください（最大 3 レベル）
  • 可能な限り、関数を集中的に保ち、50 行未満にしてください
  • 可能な限り、ファイルを集中的に保ち、200 行未満のコードにしてください

使用する場合

このスキルは、概要に記載されたワークフローまたはアクションを実行する場合に適用できます。

例

ユーザーのリクエスト:

このタスクに @software-architecture を使用してください: 品質重視のソフトウェアアーキテクチャのためのガイド。

制限事項

  • このスキルは、タスクが上記の範囲に明確に一致する場合にのみ使用してください。
  • 出力を、環境固有の検証、テスト、または専門家によるレビューの代替として扱わないでください。
  • 必要な入力、権限、安全性の境界、または成功基準が欠けている場合は、停止して確認を求めてください。

コメント

Markdown 対応