Compétences architecture-patterns
📦

architecture-patterns

Sûr

バックエンドアーキテクチャパターンの実装

Également disponible depuis: Barnhardt-Enterprises-Inc,AdamManuel-dev

保守性の高いバックエンドシステムを構築するには、実証済みのアーキテクチャパターンが必要です。このスキルは、Clean Architecture、Hexagonal Architecture、Domain-Driven Design を実装して、関心の分離を適切に保ちながら、テスト可能でスケーラブルなアプリケーションを作成するのに役立ちます。

Prend en charge: Claude Codex Code(CC)
📊 71 Adéquat
1

Télécharger le ZIP du skill

2

Importer dans Claude

Allez dans Paramètres → Capacités → Skills → Importer un skill

3

Activez et commencez à utiliser

Tester

Utilisation de "architecture-patterns". Create a Clean Architecture structure for a user management system

Résultat attendu:

このスキルは、domain/entities に User エンティティ、domain/interfaces に IUserRepository ポート、use_cases に CreateUserUseCase と UpdateUserUseCase、adapters/repositories に PostgresUserRepository 実装、adapters/controllers に HTTP 処理のための UserController を含む完全なディレクトリ構造を生成します。各コンポーネントは適切な依存関係の流れと関心の分離を示します。

Utilisation de "architecture-patterns". Implement a payment gateway adapter using hexagonal architecture

Résultat attendu:

このスキルは、charge メソッドの契約を定義する PaymentGatewayPort インターフェースを作成し、続いて本番用の StripePaymentAdapter とテスト用の MockPaymentAdapter の両方を実装します。両アダプタは同じポートインターフェースを実装するため、ビジネスロジックを変更せずに容易に差し替えできます。例にはエラーハンドリングと適切な async/await パターンが含まれます。

Utilisation de "architecture-patterns". Design an Order aggregate with DDD patterns

Résultat attendu:

このスキルは、add_item、calculate_total、submit メソッドでビジネスルールをカプセル化したアグリゲートルートとして Order エンティティを設計します。OrderItem エンティティ、通貨処理のための Money バリューオブジェクト、状態管理のための OrderStatus enum、OrderSubmittedEvent などのドメインイベントを含みます。アグリゲートは不変条件を強制し、一貫性境界を維持します。

Audit de sécurité

Sûr
v5 • 1/21/2026

All 43 static analysis findings are false positives from educational code examples in documentation. The skill teaches software architecture patterns through Python examples showing Clean Architecture, Hexagonal Architecture, and Domain-Driven Design. No executable code, network access, or security vulnerabilities present.

2
Fichiers analysés
909
Lignes analysées
0
résultats
5
Total des audits
Aucun problème de sécurité trouvé

Score de qualité

38
Architecture
100
Maintenabilité
87
Contenu
31
Communauté
100
Sécurité
91
Conformité aux spécifications

Ce que vous pouvez construire

新規バックエンドサービスのアーキテクチャ設計

適切なレイヤー分離、依存性注入、テスト可能なビジネスロジックを備えた Clean Architecture の原則で新しいマイクロサービスを計画・実装する。

モノリシックアプリケーションのリファクタリング

密結合なモノリシックアプリケーションを、テストと保守が容易なポートとアダプタを備えた整然とした Hexagonal Architecture に変換する。

Domain-Driven Design パターンの実装

アグリゲート、エンティティ、バリューオブジェクト、ドメインイベントを含む DDD の戦術的パターンで複雑なビジネスドメインをモデリングし、ドメイン整合性を高める。

Essayez ces prompts

Clean Architecture 構造の生成
Create a Clean Architecture folder structure for an e-commerce order management system with domain entities, use cases, and adapters.
リポジトリのポートとアダプタの実装
Implement a user repository port interface and PostgreSQL adapter following hexagonal architecture principles with async database access.
ビジネスロジックを持つドメインエンティティの作成
Design an Order aggregate with domain entities, value objects, and business rules for adding items, calculating totals, and state transitions.
コントローラをユースケースパターンへリファクタリング
Refactor this FastAPI endpoint that has business logic in the controller into a proper use case with dependency injection and separation of concerns.

Bonnes pratiques

  • 依存関係は常に外側のレイヤーから内側へ向け、ドメインレイヤーがインフラに依存しないようにする
  • ドメインレイヤーで契約を定義するためにインターフェースとポートを使い、外側レイヤーでテスト可能性のためのアダプタを実装する
  • ビジネスロジックはドメインエンティティとユースケースに保持し、コントローラは HTTP の関心事のみを扱いユースケースに委譲する

Éviter

  • ユースケースやドメインエンティティではなく、コントローラや API ハンドラにビジネスロジックを置く
  • データプロパティのみで振る舞いがない貧血なドメインモデルを作り、ロジックをすべてサービスに置く
  • 抽象化インターフェースなしにドメインレイヤーを特定のフレームワーク、データベース、外部 API に密結合させる

Foire aux questions

Clean Architecture とよりシンプルなパターンはいつ使い分けるべきですか?
複数の統合と長期保守が必要な複雑なビジネスロジックには Clean Architecture を使用します。基本的なワークフローの単純な CRUD アプリケーションは追加の抽象化レイヤーの恩恵が小さい場合があります。プロジェクトの複雑さに応じて、保守性とシンプルさのトレードオフを検討してください。
Hexagonal Architecture は Clean Architecture とどう違いますか?
どちらも依存関係逆転と関心の分離を強制します。Clean Architecture は内向きに依存関係が流れる厳格なルールを持つ同心円のレイヤーを重視します。Hexagonal Architecture はポートとアダプタに焦点を当て、ドメインコアを交換可能なアダプタが取り囲みます。両者は補完的で、しばしば併用されます。
DDD におけるエンティティとバリューオブジェクトの違いは何ですか?
エンティティは固有の同一性とライフサイクルを持ち、属性が同じでも ID が異なれば別物です。バリューオブジェクトは属性によって定義され不変で、同じ属性を持つものは等しいと見なされます。時間とともに変化するものはエンティティ、記述的な特性にはバリューオブジェクトを使います。
リポジトリや外部サービスに依存するユースケースはどのようにテストすればよいですか?
依存性注入を使って、リポジトリやサービスのインターフェースに対するモック実装を提供します。同じポートインターフェースを実装し、実データベースや API にアクセスせずに制御されたデータを返すテストダブルを作成します。これにより、インフラ依存なしにビジネスロジックを独立してテストできます。
これらのパターンは既存コードベースにも適用できますか、それとも新規プロジェクトだけですか?
既存コードをこれらのパターンへ段階的にリファクタリングできます。まず 1 つのモジュールや機能から始め、ビジネスロジックをユースケースへ抽出し、リポジトリインターフェースを作成してアダプタを実装します。全面的な書き換えより段階的移行の方が安全です。変化の大きい領域から着手すると効果が最大化します。
このスキルは FastAPI と PostgreSQL 以外のフレームワークでも使えますか?
原則はどのフレームワークやデータベースにも適用できます。例では FastAPI と PostgreSQL を使っていますが、Django、Flask、Express、MongoDB、MySQL など他の技術でも同じパターンが有効です。重要なのはフレームワーク固有のコードを外側のアダプタレイヤーに保ち、ビジネスロジックから分離することです。

Détails du développeur

Structure de fichiers

📄 SKILL.md