Vue d’ensemble de l’architecture
Traduction
Cette page est une traduction de la version anglaise, qui fait foi.
Balyze est conçu comme un SaaS backend-first, avec une attention particulière portée à la clarté du domaine, à la maintenabilité long terme et à une complexité technique maîtrisée.
À son stade ALPHA actuel, l’architecture se concentre sur la construction de fondations solides plutôt que sur une optimisation prématurée de la performance ou de la scalabilité.
Objectifs architecturaux
L’architecture de Balyze vise à :
- rendre les règles métier explicites et applicables
- séparer clairement les responsabilités entre les différentes couches
- minimiser la dette technique dès les premières étapes
- permettre une extension progressive sans refactorisation majeure
Le système est volontairement simple, mais pas simpliste.
Structure globale
Balyze suit une approche MVC classique, enrichie par des couches orientées domaine explicites :
-
Models
Représentent les entités métier persistées et leurs relations. -
Services
Encapsulent la logique métier et les règles du domaine.
Toute action non triviale est implémentée à ce niveau. -
Policies / Gates
Gèrent les règles d’autorisation et de propriété, indépendamment de la logique métier. -
Enums
Représentent des états métier finis et leurs transitions (par exemple le cycle de vie d’une candidature).
Les contrôleurs restent volontairement fins et se limitent à orchestrer les requêtes en déléguant aux services.
Approche orientée domaine
Les règles métier sont définies avant les détails d’implémentation.
Exemples :
- contraintes du cycle de vie d’une candidature
- règles d’éditabilité après soumission
- périmètres de propriété et d’accès
Ces règles sont documentées explicitement et appliquées de manière cohérente au niveau des services.
Séparation des responsabilités
Chaque couche possède une responsabilité unique :
- les contrôleurs gèrent les aspects HTTP
- les services prennent les décisions métier
- les modèles représentent l’état, pas l’orchestration du comportement
- les policies gèrent l’autorisation, pas la validité métier
Cette séparation réduit le couplage et rend les évolutions futures plus prévisibles.
Hors périmètre volontaire
Au stade ALPHA, les aspects suivants sont volontairement reportés :
- conception d’une API publique
- architecture frontend
- analytics avancés
- optimisations de performance au-delà de réglages raisonnables
Ces sujets seront abordés progressivement une fois le cœur métier validé.
Évolution et stabilité
L’architecture est destinée à évoluer, mais ses principes fondamentaux doivent rester stables.
Les changements structurels doivent être motivés par :
- des besoins métier validés
- des limitations concrètes rencontrées
- des décisions architecturales explicites
Toute abstraction prématurée est évitée par conception.