Décisions architecturales avant de générer du code

Type de projet

Avant de courir lino project new, définir l’objectif du système. Un projet administratif interne, un SaaS multi-tenant, un API public et une plateforme distribuée ont des besoins différents.

• Application simple : peu de contextes, déploiement unique et faible besoin d’indépendance opérationnelle.
• Monolithe modulaire : plusieurs modules dans le même processus, avec des limites explicites et des coûts opérationnels inférieurs.
• Microservices : services séparés, déploiement indépendant, communication asynchrone et plus grande complexité opérationnelle.
• SaaS : nécessite l'isolement des tenants, une sécurité renforcée, des secrets, une limitation des tarifs, de l'observabilité et des décisions claires en matière de facturation/d'exploitation.

Cette décision définit également quelles préoccupations devraient surgir dès le premier jour. Un SaaS ne peut pas traiter le tenant comme un détail tardif ; un API public ne peut pas naître sans limitation des tarifs et sans contrats clairs ; une solution avec des événements doit penser à Outbox, à l'idempotence et à l'observabilité ; une application avec plusieurs cultures doit éviter les chaînes dispersées dès le début.

Lors de la création de la fondation, enregistrez les principaux choix : cultures prises en charge, cache distribué, communication asynchrone, analyseurs de code, type de base de données, présence de l'application Web, authentification, tenant et travailleur. Ces options affectent les packages, les templates, AppHost, les paramètres, les secrets, les projets générés et l'effort requis pour modifier l'architecture ultérieurement.

Microservices modulaires et modulaires monolithiques

Le monolithe modulaire vous permet d'organiser le domaine en modules avec des contrats internes clairs, ce qui simplifie la construction, le débogage et le déploiement. Les microservices ne sont payants que lorsqu'il existe de bonnes raisons: une échelle indépendante, des équipes distinctes, des frontières commerciales stables ou des exigences opérationnelles différentes.

Commencer par un monolithe modulaire ne signifie pas ignorer l’architecture. Cela signifie préserver un déploiement simple pendant que le domaine est encore en cours de découverte, mais créer des limites internes qui empêchent que tout ne devienne une masse unique d'entités, de services et de tables partagées. C’est la différence entre « démarrer simplement » et « démarrer sans structure ».

Lino prend en charge les deux chemins. La décision doit suivre le domaine et la capacité opérationnelle de l'équipe, et pas seulement les préférences techniques. Les microservices nécessitent l'automatisation du déploiement, l'observabilité distribuée, la gestion des versions des contrats, la tolérance aux pannes du réseau, la messagerie, le retraitement et la gouvernance des données. Si l’équipe ne peut pas encore l’exploiter en toute sécurité, une distribution trop précoce augmente souvent le risque.

Utilisez un monolithe modulaire lorsque la priorité est d'apprendre le domaine, de valider le produit et de garder l'opération contrôlable. Utilisez des microservices lorsque l’indépendance opérationnelle est déjà un besoin concret: échelle distincte, équipes réellement propriétaires, cycle de publication indépendant ou exigences d’infrastructure incompatibles entre les parties du système.

Limites des services et des modules

Une bonne limite réduit le couplage et indique clairement à qui appartient chaque règle. Évitez de créer des services par table ou par écran. Les services et modules doivent représenter les capacités métier.

• Catalogue: produits, catégories, informations commerciales et données consultées par les commerciaux.
• Ventes: commandes, panier, prix appliqués, instantanés et flux commercial.
• Action: disponibilités, réservations et mouvements.
• Sécurité: utilisateurs, rôles, autorisations, authentification et jetons.

Une bonne limite a son propre langage, des règles qui changent ensemble, des données clairement définies et des contrats explicites pour communiquer avec d'autres contextes. Une mauvaise limite apparaît généralement comme un module « Commun », une entité partagée par plusieurs zones, un tableau consulté par tout le monde ou un service créé simplement parce qu'il y a eu un nouvel écran.

Lorsqu'un module a besoin des données d'un autre, choisissez entre API, un événement d'intégration, une shadow entity ou un remodelage des limites. L'accès direct à la rive d'un autre module est le signe d'un couplage structurel. Même lorsque deux modules s'exécutent dans le même processus et utilisent la même base de données physique, le schéma, les projets de persistance et les contrats doivent protéger les limites métier.

• Signe de bonne limite : le module peut faire évoluer ses entités et ses migrations sans forcer un autre module à se recompiler en raison de détails internes.
• Signal de seuil faible : une simple modification d'une entité nécessite de revoir les écrans, les requêtes et les gestionnaires de modules qui ne devraient pas connaître cette entité.
• Signe de dépendance caché : le consommateur a besoin de « trop en savoir » sur les tableaux, les domaines techniques ou le règlement intérieur du producteur.

Dette technique consciente

La dette technique n’est pas n’importe quelle imperfection. C'est une décision de reporter la qualité en connaissant le coût futur. Le problème est de créer une dette sans nom, sans propriétaire et sans plan de paiement.

Dans un système SaaS ou modulaire, la dette technique la plus dangereuse n'est pas seulement une longue méthode. C'est la dette qui limite l'évolution: modules qui ne peuvent pas changer séparément, données tenants sans isolation fiable, secrets au sein du référentiel, points de terminaison sensibles sans limites, événements sans retraitement ou intégrations sans contrat clair.

• Documentez les raccourcis pris pendant la génération et la personnalisation.
• Exécutez la compilation et les tests avant de passer à l'étape de génération suivante.
• Évitez de résoudre les problèmes générés par des hacks locaux répétés ; ajustez le motif ou le modèle lorsque le motif est erroné.

Traitez chaque décision architecturale comme vérifiable. Si vous choisissez de ne pas activer la messagerie, notez que les flux actuels ne reposent pas sur un traitement asynchrone. Si vous choisissez une colonne par tenant, assurez-vous des filtres et des tests. Si vous choisissez l'intégration synchrone, prenez en compte les délais d'attente, l'indisponibilité et les erreurs de contrat dans le cadre de la conception.

Stratégies de communication

Choisir la communication en fonction du besoin réel de cohérence, de latence, de traçabilité et de couplage. La question principale n’est pas « quelle technologie utiliser ? », mais « le producteur a besoin de la réponse maintenant, si le consommateur n’annule pas l’opération et à qui appartiennent les données ? ».

Dans les systèmes modulaires, l'erreur la plus courante est de transformer la communication en dépendance cachée: un module interroge la table d'un autre, réutilise une entité interne, injecte un référentiel externe ou crée un appel synchrone sans gérer l'échec. Cela semble productif au début, mais cela rend chaque changement ultérieur plus risqué car la frontière n’est plus explicite.

• Appel synchrone : bon pour consultation immédiate et dépendance acceptable. A éviter dans les longues cascades.
• Événement de domaine : réaction interne dans la même limite d'application.
• Événement d'intégration : communication entre modules, services ou systèmes, normalement avec Outbox.
• Entités fantômes : Copie locale minimum pour consultation et validation sans dépendre directement du producteur.
• Intégration externe HTTP : adapté aux services tiers, avec délai d'attente, nouvelle tentative, journaux et gestion des échecs.

Si la règle nécessite une mise à jour immédiate, utilisez le flux synchrone ou revoyez la limite. Si vous acceptez une cohérence éventuelle, préférez les événements pour réduire le couplage. Lorsque le consommateur n’a besoin de lire qu’un petit sous-ensemble de données provenant d’un autre contexte, une shadow entity peut être plus sûre que d’exposer l’intégralité de l’entité d’origine.