Ce volet explique comment déplacer un tenant d’une base partagée vers une base dédiée sans arrêter l’application ni perturber les autres tenants. Le catalogue pilote le basculement, tandis que le même modèle EF Core et son filtre restent en place dans les deux modes.
La migration s’appuie sur une copie initiale, un passage temporaire en lecture seule, une copie delta et une vérification avant le cutover. Le runbook attend l’expiration du cache avant de rouvrir les écritures : les instances qui conservent encore l’ancienne connexion ne peuvent ainsi pas écrire dans la base partagée après le basculement.
Avec une base par tenant, EF Core n’a plus besoin de filtre global, de colonne TenantId ni de clé de cache de modèle spécifique : le choix du tenant passe par une chaîne de connexion résolue depuis une base catalogue.
Cette isolation simplifie le modèle, mais déplace la complexité vers l’exploitation : chaque migration doit s’appliquer à toutes les bases. L’article détaille aussi le rôle de IDesignTimeDbContextFactory pour permettre à dotnet ef de créer le contexte sans requête ni tenant actif.
Cette partie 2/4 montre comment isoler les données de chaque tenant dans son propre schéma SQL Server, sans filtre global ni colonne TenantId obligatoire. Le modèle EF Core retrouve ainsi une clé primaire simple, tandis que la frontière d’isolation est portée par la structure de la base.
Le changement central tient au cache du modèle : OnModelCreating ne s’exécute qu’une fois par modèle. Il faut intégrer le schéma à la clé via IModelCacheKeyFactory, faute de quoi EF Core peut réutiliser celui du premier tenant. L’article détaille aussi le provisionnement et les migrations par schéma, ainsi que la validation stricte des noms de schéma interpolés dans le SQL.
CodoMetis.ValueRanges propose des types d’intervalle .NET pour remplacer les paires de dates et leur logique dispersée. Les cinq variantes — finie, sans borne gauche ou droite, infinie et vide — rendent explicites les formes possibles et leurs règles, tandis que les opérations comme Contains et Overlaps s’exécutent en mémoire.
Le package EF Core associé fait le pont avec PostgreSQL : les mêmes opérations dans le domaine sont traduites en opérateurs SQL via Npgsql. L’article détaille aussi le compromis de conception : des records abstraits plutôt que des structs, pour représenter les variantes par une hiérarchie de types.
Metalama automatise les patterns transverses en C# avec des aspects qui génèrent le code à la compilation, tout en vérifiant les règles d’architecture dès l’édition. L’implémentation répétitive reste ainsi hors du code métier et du dépôt, tandis qu’un même aspect peut être appliqué à une méthode ou à un ensemble de méthodes sélectionnées par code.
Un aspect peut, par exemple, envelopper une méthode dans un try/catch pour journaliser son entrée, son résultat et ses exceptions. Metalama permet aussi de prévisualiser le code transformé et de le déboguer, pour rendre ces transformations inspectables.
REA propose une approche unifiée de l’ingénierie inverse, pilotée par des agents capables d’analyser des binaires natifs, des applications JavaScript/Electron, des sites web ou des bases de données, sans accès au code source. L’outil s’intègre à des agents comme Claude Code ou Cursor, fournit des preuves et des limites pour chaque analyse, et s’appuie sur des outils natifs (Hopper, Ghidra, IDA) pour l’analyse profonde. La documentation détaille les scénarios pris en charge, la configuration des providers et les workflows CLI, avec des exemples concrets de rétro-ingénierie de fonctionnalités d’applications existantes.
Ce panorama détaille les étapes d’organisation d’un projet React, du simple fichier à la structure modulaire d’un monorepo. L’auteur expose les choix de découpage (fichiers, dossiers techniques, dossiers de fonctionnalités, domaines, packages) et leurs impacts sur la maintenabilité, l’isolation des dépendances et la scalabilité. Les exemples concrets montrent comment faire évoluer l’architecture selon la taille du projet, en soulignant les règles pour éviter les dépendances croisées et favoriser la réutilisation.
Patterns.dev documente des motifs de conception JavaScript et des techniques de performance pour les applications web. Les exemples aident à relier les choix d’architecture à leurs effets sur le chargement et le rendu.
Code Wiki génère des explications, références d’API et vues d’architecture à partir de dépôts publics. La documentation est organisée par sections de code pour explorer un projet sans parcourir chaque fichier manuellement.
Nakama rassemble comptes utilisateurs, stockage, chat, classements et modes multijoueurs. Le serveur fournit les briques partagées nécessaires aux jeux et applications temps réel.
Ce retour d’expérience examine les difficultés d’un déploiement Next.js horizontal. Il met en avant les aspects de cache et de coordination à considérer lorsque plusieurs instances servent la même application.
Next-forge fournit un template Turborepo séparant application, API, emails, site et documentation. Cette organisation pose les bases d’un produit Next.js comportant plusieurs surfaces.
DivKit décrit éléments, états et animations dans des données envoyées au client. Les rendus natifs Android, iOS et web permettent de faire évoluer des interfaces sans une nouvelle release pour chaque changement.
Vogen enveloppe des types primitifs dans des types métier générés. L’exemple CustomerId montre comment obtenir comparaisons et construction encadrée sans écrire tout le code répétitif.
Eraser accepte des descriptions, fichiers et extraits de code pour construire des diagrammes. Les entrées comme Terraform ou un document de conception permettent d’illustrer une architecture à discuter en équipe.
Jennifer Pahlka revient sur healthcare.gov pour défendre la progression depuis un système simple qui fonctionne. Le texte relie les risques des grands projets à la volonté de livrer toute la complexité d’un seul coup.
Ce générateur automatise les builders pour classes, structs et records. Les étapes imposent les informations obligatoires avant les options, tout en favorisant l’immutabilité des objets.
Frappe associe un backend Python à une interface JavaScript pour développer des applications métier. Son modèle de métadonnées, utilisé par ERPNext, structure les objets et leur comportement pour réduire le code répétitif.
L’article transpose les principes SOLID au développement frontend avec Vue 3. Il montre comment utiliser ces règles de conception pour structurer du code plus maintenable au-delà des seuls détails du framework.
Damien Bod propose de représenter les flux d’authentification et d’autorisation dans un modèle de contexte. Cette approche aide à repérer les frontières de confiance et les erreurs de conception avant l’implémentation.
