La frontière produit est une décision stratégique.

L'architecture suit les droits de décision

Une capacité partagée n'est pas automatiquement une plateforme, et une interface client n'est pas automatiquement un produit. La vraie question est qui porte le résultat et quels changements doivent être indépendants.

La frontière doit suivre des droits durables, des niveaux de service et le rythme du changement, pas un organigramme copié dans le logiciel.

Exposer le couplage réel

Le couplage caché apparaît comme releases synchronisées, règles dupliquées, réconciliation manuelle et réunions nécessaires au changement ordinaire.

Cartographiez ces coûts avant de choisir les frontières. Parfois la séparation convient ; parfois un domaine partagé plus fort simplifie le système.

• Qui peut changer une règle sans permission ?
• Quels échecs doivent rester isolés ?
• Où l'état devient-il autoritaire ?
• Quelle capacité a un client interne ?

Progresser vers la preuve

Une architecture cible est une hypothèse. Prouvez une tranche complète qui traverse la frontière, mesurez les transferts et ajustez avant de la multiplier.

La meilleure frontière n'est pas la plus à la mode, mais celle qui réduit le coût des changements réellement nécessaires.