Dessiner un diagramme de composants

Avant de dessiner quoi que ce soit, faites une liste. Pas de vos modules, pas de vos dossiers : des parties du système que l'on pourrait plausiblement échanger contre une autre implémentation - achetées plutôt que construites, réécrites par une autre équipe, ou exploitées par quelqu'un d'autre.

Cette question est tout le filtre. Un dossier n'est pas un composant, une classe non plus ; une chose dotée d'une frontière que l'on pourrait confier à un fournisseur, si. Le système de reporting de cet article en a donné quatre : un tableau de bord, un ordonnanceur qui lance les rapports la nuit, le service de rapports lui-même, et un adaptateur qui parle à l'entrepôt de données.

Placez les pièces et résistez à l'envie de les relier. Dessiner des flèches maintenant revient à les tracer entre composants, et un trait du Dashboard directement au service de rapports ne dit que « ces deux-là sont impliqués d'une manière ou d'une autre », c'est-à-dire exactement le flou qu'un diagramme de composants existe pour supprimer.

La mise en page vaut trente secondes ici : les consommateurs d'un côté, les fournisseurs de l'autre. Tous les diagrammes de cette série sont dessinés de gauche à droite, les dépendances allant dans un seul sens, parce que le lecteur vérifie alors la direction d'un coup d'œil plutôt qu'en suivant chaque trait.

Pour chaque boîte, demandez-vous sur quoi quelqu'un d'extérieur a le droit de compter, et nommez-le. Ici IReports et IWarehouse - un contrat par capacité, pas un par consommateur. Rattachez-le par une réalisation : trait pointillé, triangle creux, pointant vers l'interface.

C'est à cette étape que se fait la vraie conception, et c'est l'étape que l'on saute. Nommer un contrat oblige à décider ce qui est public, et la dispute qui suit - « l'export CSV fait-il partie d'IReports ou non ? » - est celle qu'il vaut mieux avoir avant que deux équipes y répondent différemment dans le code.

Vient la seconde moitié, celle qui porte l'information : de quels contrats chaque composant a-t-il besoin ? Tracez une dépendance - trait pointillé, pointe ouverte - du composant vers l'interface qu'il requiert. Le résultat est le diagramme en tête de cet article.

Deux choses deviennent visibles dès que ces flèches se posent. Le tableau de bord et l'ordonnanceur pointent tous deux vers IReports : le modifier est désormais visiblement un changement pour deux consommateurs. Et le service de rapports pointe vers IWarehouse et non vers l'adaptateur, donc l'adaptateur est remplaçable sans que le service s'en aperçoive - ce qui est soit ce que vous vouliez, soit une découverte qu'il vaut mieux faire maintenant.

Un diagramme de composants est terminé quand il y survit. Elles prennent une minute, et chacune a plus souvent attrapé un vrai problème qu'elle n'est passée sans rien dire.

1. Masquez une boîte avec la main. Ce qui reste - les interfaces qui y étaient rattachées - est la spécification de son remplaçant. Si ce remplaçant devait savoir quelque chose qui n'est pas à l'écran, la frontière est au mauvais endroit.
2. Suivez les flèches à la recherche d'un cycle. Deux composants qui se requièrent mutuellement ne peuvent être déployés, testés ni remplacés indépendamment. Voyez le dernier des exemples détaillés pour ce à quoi cela ressemble et comment on le casse.
3. Vérifiez que chaque composant a au moins une interface. Une boîte à laquelle rien n'est rattaché n'est pas un composant, ou n'a rien à faire sur ce diagramme.
4. Lisez les noms d'interfaces à voix haute. Si l'un est nommé d'après son fournisseur actuel plutôt que d'après sa capacité - IMainframeBilling au lieu d'IBilling - le contrat a le fournisseur cuit dedans, et l'échange que le diagramme promet ne sera pas aussi propre qu'il en a l'air.

La colonne de droite n'est pas du pédantisme sur les types de diagrammes. Chaque élément agrandit l'image sans répondre à la question pour laquelle le diagramme a été dessiné, et chacun lui donne une seconde raison de se périmer : un diagramme de composants traverse un changement de plateforme intact, le même dessin avec deux régions AWS dessus, non.

Le dessin fait, la référence de chaque signe qui s'y trouve est dans les symboles du diagramme de composants, et l'argumentaire plus large sur les cas où ce type de diagramme vaut l'effort est dans le guide du diagramme de composants.