Un modèle, Runtime local ou distant

Statut documentaire : architecture. La compacité et le support d'une cible ne deviennent des affirmations étayées que lorsqu'un enregistrement de benchmark/plateforme existe.

L'invariant architectural utile n'est pas un chiffre de taille. C'est le fait que le code applicatif peut dépendre du même contrat conceptuel/public tandis que le placement du Runtime change en dessous.

API générée
  -> IClientRuntime
     -> adaptateur local -> ABI -> Runtime
     -> adaptateur distant -> RPC -> Runtime

Un scénario de preuve pour un déploiement contraint doit utiliser le même modèle métier dans les deux placements : charger le modèle, demander une action publiée, laisser une règle déclarée l'accepter ou la refuser, capturer la trace conceptuelle, puis exécuter le même contrat face à un placement distant/serveur.

Ce que cela prouve dépend des mesures. Ne transformez pas une démonstration sur un appareil en revendication générique de supériorité. N'enregistrez temps de démarrage, mémoire résidente, empreinte disque, dépendances et lacunes de capacité que sous un protocole nommé.

Pour les développeurs applicatifs, le placement doit rester sous les services métier sauf si la localité fait elle-même partie du besoin métier.