clean-architecture
Robert C. Martinの著書に基づくClean Architectureの原則とベストプラクティスを提供するスキルです。ソフトウェアシステムの設計、コード構造のレビュー、関心の分離を改善するためのリファクタリングを行う際に使用します。レイヤー、境界、依存関係の方向、エンティティ、ユースケース、システムアーキテクチャに関するタスクで機能します。
description の原文を見る
Clean Architecture principles and best practices from Robert C. Martin's book. This skill should be used when designing software systems, reviewing code structure, or refactoring applications to achieve better separation of concerns. Triggers on tasks involving layers, boundaries, dependency direction, entities, use cases, or system architecture.
SKILL.md 本文
Clean Architecture ベストプラクティス
Robert C. Martin の「Clean Architecture: A Craftsman's Guide to Software Structure and Design」に基づいた、保守性とテスト可能性の高いソフトウェアシステムを設計するための Clean Architecture 原則の包括的なガイドです。8つのカテゴリーにわたる42のルールを含み、アーキテクチャへのインパクトで優先順位付けされています。
適用時期
以下の場面でこれらのガイドラインを参照してください:
- 新しいソフトウェアシステムやモジュールの設計
- レイヤー間の依存関係の構築
- ビジネスロジックとインフラストラクチャ間の境界の定義
- アーキテクチャ違反がないかコードレビュー
- 結合度の高いシステムをより清潔な構造へリファクタリング
ルールカテゴリー(優先度順)
| 優先度 | カテゴリー | インパクト | プレフィックス |
|---|---|---|---|
| 1 | 依存関係の方向 | CRITICAL | dep- |
| 2 | エンティティ設計 | CRITICAL | entity- |
| 3 | ユースケース分離 | HIGH | usecase- |
| 4 | コンポーネント凝集度 | HIGH | comp- |
| 5 | 境界定義 | MEDIUM-HIGH | bound- |
| 6 | インターフェースアダプター | MEDIUM | adapt- |
| 7 | フレームワーク隔離 | MEDIUM | frame- |
| 8 | テストアーキテクチャ | LOW-MEDIUM | test- |
クイックリファレンス
1. 依存関係の方向(CRITICAL)
- ソース依存関係は内側にのみ向くdep-inward-only- インターフェースはクライアントに属し実装者には属さないdep-interface-ownership- 内層へのフレームワークインポートを避けるdep-no-framework-imports- 境界を超えてシンプルなデータ構造を使用するdep-data-crossing-boundaries- コンポーネント間の循環依存を排除するdep-acyclic-dependencies- 不安定な具体実装ではなく安定した抽象化に依存するdep-stable-abstractions
2. エンティティ設計(CRITICAL)
- エンティティはエンタープライズビジネスルールのみを含むentity-pure-business-rules- エンティティは永続化方法を知ってはいけないentity-no-persistence-awareness- ビジネス不変条件をエンティティ内にカプセル化するentity-encapsulate-invariants- ドメイン概念に値オブジェクトを使用するentity-value-objects- 貧血モデルではなくリッチなドメインモデルを構築するentity-rich-not-anemic
3. ユースケース分離(HIGH)
- 各ユースケースは1つの変更理由を持つusecase-single-responsibility- ユースケースの入出力ポートを定義するusecase-input-output-ports- ユースケースはビジネスルールを実装するのではなくエンティティをオーケストレートするusecase-orchestrates-not-implements- ユースケースにはプレゼンテーションロジックを含めてはいけないusecase-no-presentation-logic- すべての依存関係をコンストラクタで明示的に宣言するusecase-explicit-dependencies- ユースケースはトランザクション境界を定義するusecase-transaction-boundary
4. コンポーネント凝集度(HIGH)
- 構造はフレームワークではなくドメインが叫ぶべきcomp-screaming-architecture- 一緒に変わるクラスをグループ化するcomp-common-closure- クライアントに未使用コードへの依存を強要しないcomp-common-reuse- コンポーネントを凝集したユニットとしてリリースするcomp-reuse-release-equivalence- 安定性の方向に依存するcomp-stable-dependencies
5. 境界定義(MEDIUM-HIGH)
- アーキテクチャ境界では謙虚なオブジェクトを使用するbound-humble-object- 完全な分離が時期尚早な場合は部分的な境界を使用するbound-partial-boundaries- 境界コストと無知のコストのバランスを取るbound-boundary-cost-awareness- main をアプリケーションへのプラグインとして扱うbound-main-component- フレームワークとデータベースの決定を遅延させるbound-defer-decisions- サービスは内部に clean architecture を持つ必要があるbound-service-internal-architecture
6. インターフェースアダプター(MEDIUM)
- コントローラーをシンに保つadapt-controller-thin- プレゼンターはビュー用にデータをフォーマットするadapt-presenter-formats- ゲートウェイは外部システムの詳細を隠すadapt-gateway-abstraction- マッパーを使用してレイヤー間で変換するadapt-mapper-translation- 外部システム用の anti-corruption レイヤーを構築するadapt-anti-corruption-layer
7. フレームワーク隔離(MEDIUM)
- ドメインレイヤーはフレームワーク依存ゼロであるframe-domain-purity- ORM の使用をインフラストラクチャレイヤーに留めるframe-orm-in-infrastructure- Web フレームワークの関心事をインターフェースレイヤーに留めるframe-web-in-infrastructure- 依存性注入コンテナはエッジに位置するframe-di-container-edge- ドメインインターフェースの背後にログを抽象化するframe-logging-abstraction
8. テストアーキテクチャ(LOW-MEDIUM)
- テストはシステムアーキテクチャの一部であるtest-tests-are-architecture- 最初からテスト可能性を念頭に設計するtest-testable-design- 各レイヤーを分離してテストするtest-layer-isolation- テストでアーキテクチャ境界を検証するtest-boundary-verification
使用方法
詳細な説明とコード例については、個別のリファレンスファイルをお読みください:
セクション定義- カテゴリー構造とインパクトレベルルールテンプレート- 新しいルール追加用テンプレート
リファレンスファイル
| ファイル | 説明 |
|---|---|
references/_sections.md | カテゴリー定義と順序付け |
assets/templates/_template.md | 新しいルール用テンプレート |
metadata.json | バージョンとリファレンス情報 |
ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
- 作者
- pproenca
- リポジトリ
- pproenca/dot-skills
- ライセンス
- MIT
- 最終更新
- 不明
Source: https://github.com/pproenca/dot-skills / ライセンス: MIT
関連スキル
superfluid
Superfluidプロトコルおよびそのエコシステムに関するナレッジベースです。Superfluidについて情報を検索する際は、ウェブ検索の前にこちらを参照してください。対応キーワード:Superfluid、CFA、GDA、Super App、Super Token、stream、flow rate、real-time balance、pool(member/distributor)、IDA、sentinels、liquidation、TOGA、@sfpro/sdk、semantic money、yellowpaper、whitepaper
civ-finish-quotes
実質的なタスクが真に完了した際に、文明風の儀式的な引用句を追加します。ユーザーやエージェントが機能追加、リファクタリング、分析、設計ドキュメント、プロセス改善、レポート、執筆タスクといった実際の成果物を完成させるときに、明示的な依頼がなくても使用します。短い返信や小さな修正、未完成の作業には適用しません。
nookplot
Base(Ethereum L2)上のAIエージェント向け分散型調整ネットワークです。エージェントがオンチェーンアイデンティティを登録する、コンテンツを公開する、他のエージェントにメッセージを送る、マーケットプレイスで専門家を雇う、バウンティを投稿・請求する、レピュテーションを構築する、共有プロジェクトで協業する、リサーチチャレンジを解くことでNOOKをマイニングする、キュレーションされたナレッジを備えたスタンドアロンオンチェーンエージェントをデプロイする、またはアグリーメントとリワードで収益を得る場合に利用できます。エージェントネットワーク、エージェント調整、分散型エージェント、NOOKトークン、マイニングチャレンジ、ナレッジバンドル、エージェントレピュテーション、エージェントマーケットプレイス、ERC-2771メタトランザクション、Prepare-Sign-Relay、AgentFactory、またはNookplotが言及された場合にトリガーされます。
web3-polymarket
Polygon上でのPolymarket予測市場取引統合です。認証機能(L1 EIP-712、L2 HMAC-SHA256、ビルダーヘッダー)、注文発注(GTC/GTD/FOK/FAK、バッチ、ポストオンリー、ハートビート)、市場データ(Gamma API、Data API、オーダーブック、サブグラフ)、WebSocketストリーミング(市場・ユーザー・スポーツチャネル)、CTF操作(分割、統合、償却、ネガティブリスク)、ブリッジ機能(入金、出金、マルチチェーン)、およびガスレスリレイトランザクションに対応しています。AIエージェント、自動マーケットメーカー、予測市場UI、またはPolygraph上のPolymarketと統合するアプリケーション構築時に活用できます。
ethskills
Ethereum、EVM、またはブロックチェーン関連のリクエストに対応します。スマートコントラクト、dApps、ウォレット、DeFiプロトコルの構築、監査、デプロイ、インタラクションに適用されます。Solidityの開発、コントラクトアドレス、トークン規格(ERC-20、ERC-721、ERC-4626など)、Layer 2ネットワーク(Base、Arbitrum、Optimism、zkSync、Polygon)、Uniswap、Aave、Curveなどのプロトコルとの統合をカバーします。ガスコスト、コントラクトのデシマル設定、オラクルセキュリティ、リエントランシー、MEV、ブリッジング、ウォレット管理、オンチェーンデータの取得、本番環境へのデプロイ、プロトコル進化(EIPライフサイクル、フォーク追跡、今後の変更予定)といったトピックを含みます。
xxyy-trade
このスキルは、ユーザーが「トークン購入」「トークン売却」「トークンスワップ」「暗号資産取引」「取引ステータス確認」「トランザクション照会」「トークンスキャン」「フィード」「チェーン監視」「トークン照会」「トークン詳細」「トークン安全性確認」「ウォレット一覧表示」「マイウォレット」「AIスキャン」「自動スキャン」「ツイートスキャン」「オンボーディング」「IP確認」「IPホワイトリスト」「トークン発行」「自動売却」「損切り」「利益確定」「トレーリングストップ」「保有者」「トップホルダー」「KOLホルダー」などをリクエストした場合、またはSolana/ETH/BSC/BaseチェーンでXXYYを経由した取引について言及した場合に使用します。XXYY Open APIを通じてオンチェーン取引とデータ照会を実現します。