architecture-patterns
Mettre en oeuvre des patterns d'architecture backend
Également disponible depuis: Barnhardt-Enterprises-Inc,AdamManuel-dev
Construire des systemes backend maintenables exige des patterns d'architecture eprouves. Cette competence vous aide a mettre en oeuvre Clean Architecture, Hexagonal Architecture et Domain-Driven Design pour creer des applications testables et evolutives avec une separation des preoccupations appropriee.
Télécharger le ZIP du skill
Importer dans Claude
Allez dans Paramètres → Capacités → Skills → Importer un skill
Activez et commencez Ă utiliser
Tester
Utilisation de "architecture-patterns". Create a Clean Architecture structure for a user management system
RĂ©sultat attendu:
La competence genere une structure de repertoires complete avec domain/entities contenant l'entite User, domain/interfaces avec le port IUserRepository, use_cases contenant CreateUserUseCase et UpdateUserUseCase, adapters/repositories avec l'implementation PostgresUserRepository, et adapters/controllers avec UserController pour la gestion HTTP. Chaque composant demontre un flux de dependances correct et une separation des preoccupations.
Utilisation de "architecture-patterns". Implement a payment gateway adapter using hexagonal architecture
RĂ©sultat attendu:
La competence cree une interface PaymentGatewayPort definissant le contrat de la methode charge, puis implemente StripePaymentAdapter pour la production et MockPaymentAdapter pour les tests. Les deux adaptateurs implementent la meme interface de port, permettant un remplacement facile sans modifier la logique metier. L'exemple inclut la gestion des erreurs et des patterns async/await corrects.
Utilisation de "architecture-patterns". Design an Order aggregate with DDD patterns
RĂ©sultat attendu:
La competence conçoit une entite Order comme aggregate root avec les methodes add_item, calculate_total et submit encapsulant les regles metier. Elle inclut l'entite OrderItem, le value object Money pour la gestion des devises, l'enum OrderStatus pour la gestion d'etat, et des domain events comme OrderSubmittedEvent. L'aggregate fait respecter les invariants et maintient les frontieres de coherence.
Audit de sécurité
SûrAll 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.
Score de qualité
Ce que vous pouvez construire
Concevoir une nouvelle architecture de service backend
Planifier et implementer un nouveau microservice en appliquant les principes de Clean Architecture avec une separation des couches appropriee, l'injection de dependances et une logique metier testable.
Refactorer une application monolithique
Transformer une application monolithique fortement couplee en une architecture hexagonale bien structuree avec ports et adaptateurs pour des tests et une maintenance facilites.
Mettre en oeuvre des patterns Domain-Driven Design
Modeliser des domaines metier complexes avec les patterns tactiques DDD, dont aggregates, entites, value objects et domain events, pour un meilleur alignement sur le domaine.
Essayez ces prompts
Creer une structure de dossiers Clean Architecture pour un systeme de gestion des commandes e-commerce avec entites de domaine, use cases et adaptateurs.
Implementer une interface de port de repository utilisateur et un adaptateur PostgreSQL suivant les principes d'architecture hexagonale avec acces base de donnees asynchrone.
Concevoir un aggregate Order avec des entites de domaine, des value objects et des regles metier pour ajouter des elements, calculer les totaux et gerer les transitions d'etat.
Refactorer cet endpoint FastAPI qui contient de la logique metier dans le controller en un use case approprie avec injection de dependances et separation des preoccupations.
Bonnes pratiques
- Toujours diriger les dependances vers l'interieur des couches externes vers les couches internes, ne jamais laisser la couche domaine dependre de l'infrastructure
- Utiliser des interfaces et des ports pour definir les contrats dans la couche domaine, implementer des adaptateurs dans les couches externes pour la testabilite
- Garder la logique metier dans les entites de domaine et les use cases, les controllers ne doivent gerer que les preoccupations HTTP et deleguer aux use cases
Éviter
- Placer la logique metier dans les controllers ou les gestionnaires d'API au lieu des use cases et des entites de domaine
- Creer des modeles de domaine anemiques avec seulement des proprietes de donnees et aucun comportement, en mettant toute la logique dans des services
- Coupler fortement la couche domaine a des frameworks, bases de donnees ou API externes specifiques sans interfaces d'abstraction