Projets liés

Embarquez visuellement un projet d'architecture dans un autre pour représenter les systèmes complexes et les interactions entre équipes.

Pour les grandes architectures, il est souvent utile de découper la documentation en plusieurs projets : un par équipe, un par domaine, un par microservice. Le Projet lié vous permet d'embarquer visuellement un projet dans un autre, pour montrer comment les systèmes interagissent sans dupliquer la documentation.

Concept#

Un projet lié s'affiche comme un conteneur : une zone qui embarque le contenu d'un autre projet, distincte d'un composant classique. Il peut être plié ou déplié.

Plié#

Le conteneur affiche un résumé compact : le nom du projet lié et une indication qu'il s'agit d'un projet embarqué.

Déplié#

Le conteneur s'agrandit et affiche les composants du projet lié, en lecture seule, avec leurs connexions internes. À sa création, un projet lié s'ouvre replié puis se déplie automatiquement.

Créer un projet lié#

  1. Dans la barre d'ajout, ouvrez l'onglet Containers et choisissez Projet lié.
  2. Déposez-le sur le canvas : une fenêtre s'ouvre pour choisir le projet à embarquer.
  3. Sélectionnez le projet, puis validez.

Seuls les projets du même workspace auxquels vous avez accès sont proposés.

Plier et déplier#

Utilisez le chevron du conteneur (ou son menu contextuel) pour déplier ou replier un projet lié à tout moment.

Contenu toujours à jour#

Par défaut, un projet lié pointe vers la dernière version du projet source : dès que celui-ci change, le projet lié reflète immédiatement les modifications, sans manipulation de votre part.

Pour figer un projet lié sur un état précis, épinglez-le sur une version nommée (tag) - une option disponible à partir du plan Pro. Voir l'historique de versions.

Récursivité#

Un projet lié peut lui-même contenir des projets liés. La profondeur n'est pas limitée : les éventuels cycles (un projet qui finit par se référencer en boucle) sont détectés automatiquement.

Permissions#

Votre accès au projet source détermine ce que vous voyez :

Votre accès au projet liéComportement
Admin / Editor / ViewerDéplier et consulter le contenu
Aucun accèsLe conteneur reste plié, avec la mention « Accès restreint »

Les utilisateurs sans accès savent qu'un projet existe, sans en voir les détails.

Connexions#

Vous pouvez relier un composant de votre projet vers un projet lié (plié ou déplié) pour représenter une interaction avec le système externe. Quand le projet lié est déplié, vous pouvez viser un composant précis à l'intérieur, pour une connexion plus fine.

Une connexion vers un composant interne est visuelle : si ce composant disparaît du projet source, la connexion peut devenir invalide.

Cas d'usage#

Vue d'ensemble système#

Vous êtes architecte système et voulez montrer comment cinq microservices interagissent :

  1. Créez un projet « Vue Système ».
  2. Ajoutez un projet lié par microservice.
  3. Connectez-les pour montrer les flux.
  4. Chaque équipe maintient son propre projet.

Présentation direction#

Pour une présentation aux dirigeants :

  1. Laissez les projets liés pliés (vue macro).
  2. Montrez les interactions principales.
  3. Dépliez ponctuellement pour répondre aux questions.

Documentation d'intégration#

Documentez comment votre service s'intègre aux systèmes partenaires :

  1. Votre service au centre.
  2. Un projet lié pour chaque système externe.
  3. Des connexions montrant les API utilisées.

Cartographie de domaine#

Pour le Domain-Driven Design :

  1. Un projet par bounded context.
  2. Un projet « Context Map » liant tous les contextes.
  3. Les relations entre contextes deviennent explicites.

Limitations#

Les composants d'un projet lié sont en lecture seule : vous ne pouvez ni les déplacer, ni modifier leurs propriétés, ni les supprimer depuis le projet hôte. Leurs connexions internes sont affichées mais non modifiables. Pour les modifier, ouvrez le projet source.

Bonnes pratiques#

Granularité#

Choisissez le bon niveau de découpage :

  • Trop de projets liés → navigation complexe.
  • Pas assez → projets monolithiques difficiles à maintenir.

Règle : un projet par équipe ou par domaine fonctionnel.

Nommage#

Adoptez une convention claire pour les noms de projets :

  • team-backend-users-service
  • domain-payments
  • infra-kubernetes-cluster

Permissions#

Assurez-vous que les utilisateurs ont les bons accès :

  • Les architectes voient tous les projets.
  • Les équipes voient leurs projets et les projets liés.
  • Les parties prenantes ont des vues simplifiées.

Documentation#

Dans le projet hôte, ajoutez des notes expliquant pourquoi ce projet est lié, quelles interactions existent, et qui contacter pour plus de détails.

Prochaines étapes#