Que fait Sélection d'architecture et contrôles de conformité ?
Traduire les objectifs en comportement observable
Identifiez les acteurs, les flux de travail critiques, la propriété des données et les contraintes. Convertissez « scalable », « sécurisé » et « maintenable » en scénarios : stimulus → environnement → réponse → mesure. Classez les quelques caractéristiques qui déterminent matériellement la conception. Distinguez les contraintes obligatoires des préférences.
Procédure
- Définissez des scénarios de qualité et des seuils d'acceptation avec les parties prenantes. Précisez les hypothèses sur la charge de travail, les pannes et l'équipe. Utilisez sélection.
- Identifiez le périmètre auquel chaque propriété doit s'appliquer : composant, déploiement, flux de travail ou système entier. Différentes parties peuvent justifier différents styles.
- Comparez un petit ensemble de styles réalisables par rapport à ces scénarios, y compris un déploiement unique modulaire. Expliquez le mécanisme soutenant chaque avantage revendiqué.
- Examinez le couplage : dépendances sources, appels runtime, données partagées et modifications coordonnées. L'indépendance statique des modules ne prouve pas l'isolation aux pannes runtime.
- Choisissez le style viable le plus simple et enregistrez une ADR, les conséquences et un déclencheur de réévaluation. Séparez les détails d'implémentation réversibles des engagements structurels coûteux.
- Transformez les décisions critiques en contrôles de conformité : dépendances interdites, compatibilité des contrats, budgets de latence, temps de restauration et isolation des locataires. Utilisez contrôles de conformité.
- Réévaluez sous charge observée et motifs de changement. Une règle de dépendance réussie est une preuve pour une propriété, pas pour la qualité globale de l'architecture.
Questions de revue
- Une frontière de plugin résout-elle des besoins réels d'extensibilité sans accorder à chaque plugin un accès illimité au cœur ?
- Les événements ont-ils besoin de publication durable, de compatibilité de schéma, de dédoublonnage et de surveillance du retard ? Ces coûts sont-ils inclus dans la proposition événementielle ?
- Un déploiement séparé améliore-t-il un goulot d'étranglement mesuré ou une contrainte de mise en production ?
- L'équipe proposée peut-elle gérer la complexité de déploiement et de défaillance résultante ?
- Quel invariant devient plus difficile lorsque la propriété des données est divisée ?
Sortie
Retournez les scénarios de qualité, les mécanismes/compromis candidats, la structure choisie, la carte de propriété/dépendances, l'ADR, les contrôles de conformité et les hypothèses non résolues.
Périmètre et références
Couverture partielle alignée sur Fundamentals of Software Architecture, 2e éd. (Richards et Ford). Le contenu de l'auteur, une transcription d'interview publique, le sommaire de l'éditeur et la documentation sur les tests d'architecture fondent ce guide original. Voir sources. Aucun style n'est un stade de maturité universel.