Ahnii!
Ceci est la première partie de la série Waaseyaa sur la gouvernance. Il explique comment Waaseyaa – un framework PHP monorepo de 52 packages – a effectué un audit architectural formel basé sur des invariants, ce qu'il a trouvé lors de cinq passes problématiques et comment l'étape 2 a transformé ces résultats en un programme de remédiation en huit étapes couvert dans la partie 2.
supplémentaire,chargement automatique, découverte de fournisseur)Waaseyaa est un framework PHP organisé dans une architecture à 7 couches réparties sur 52 packages Composer. Les couches s'étendent de L0 (infrastructure de base) jusqu'à L6 (interfaces – le SPA d'administration, le SSR et d'autres surfaces destinées aux utilisateurs). La contrainte qui rend le modèle utile est simple : les packages ne peuvent importer qu'à partir de leur propre couche ou d'une couche inférieure. La communication ascendante doit passer par des coutures sanctionnées.
Cette contrainte est facile à énoncer et difficile à maintenir. Le travail sur les fonctionnalités se déroule rapidement. Un développeur a besoin de quelque chose d'une couche supérieure, ajoute une dépendance, passe à autre chose. Un fournisseur a besoin d'accéder à un service composé du noyau et le reconstruit localement. Une commande CLI est implémentée, jamais connectée à la surface de la console enregistrée. Aucun de ces éléments n’est catastrophique individuellement. Au fil du temps, ils s'accumulent dans une base de code où le modèle architectural et le graphe de dépendances réel ont discrètement divergé.
La réponse standard est un nettoyage ad hoc : corrigez les choses au fur et à mesure que vous les remarquez, ajoutez des notes au CLAUDE.md, en espérant que l'équipe s'en souvienne. Cela fonctionne jusqu'à un certain point. Il cesse de fonctionner lorsque la divergence est suffisamment répandue pour que vous ne puissiez pas faire confiance au modèle de couche en tant qu'invariant exécutoire. À ce stade, vous avez besoin d’un audit ...
[Courte citation de 8% de l'article original]