Architecture e-commerce, modélisée

Une boutique est l'exemple vers lequel tout le monde se tourne, et si la plupart des diagrammes de boutique sont inutiles, c'est qu'ils essaient d'être une seule image. Le vocabulaire, les frontières de services et les machines sont trois sujets différents, et un dessin qui les mélange n'en traite aucun : c'est le diagramme avec une classe Order, un logo Kubernetes et une file d'attente sur la même toile.

Découpé par question, chacun devient vérifiable :

1. Quels sont les noms ? Un diagramme de classes du domaine. Ce qu'est une commande, de quoi elle est faite, sans quoi elle ne peut pas exister.
2. Qui a le droit d'appeler qui ? Un diagramme de composants des services et des contrats entre eux.
3. Où cela tourne-t-il ? Un diagramme de déploiement des noeuds et des artefacts qui s'y trouvent.

Rien ici n'est un diagramme de files, un diagramme de séquence ni un listing d'infrastructure-as-code, et c'est volontaire. Ceux-là existent et sont utiles ; ils sont aussi l'endroit où un ensemble documentaire meurt si les trois premiers ne sont pas justes.

C'est le diagramme qui règle le vocabulaire, et le vocabulaire est le premier endroit où les boutiques dérapent. Un "panier" est-il une Order non encore passée, ou une autre chose ? Une OrderLine porte-t-elle le prix au moment de l'achat, ou le lit-elle sur le Product ? La seconde question est tranchée sur la figure - unitPrice vit sur la ligne - et cet unique attribut fait la différence entre une boutique dont les anciennes factures restent justes après un changement de prix et une dont elles ne le restent pas.

La figure en tête de cet article. Deux clients, un service de commandes, et deux contrats dont il dépend : le stock et le paiement. Lisez-le en masquant une boîte : masquez le service de commandes et il reste IOrders, IStock et IPayment, c'est-à-dire exactement la spécification qu'un remplaçant devrait satisfaire.

L'adaptateur est la pièce à copier. IPaymentest un contrat que la boutique possède ; l'adaptateur Stripe le réalise. Rien dans le service de commandes ne nomme un prestataire, si bien que "que coûterait un passage à Adyen ?" a une réponse visible : une boîte, plus ce que l'adaptateur s'avère avoir laissé fuir. Dessiné dans l'autre sens, avec le service de commandes dépendant directement d'un composant Stripe, la même question demande une recherche dans le code.

Ce qui est délibérément absent : le panier, l'index de recherche, le moteur de recommandation, l'envoi d'e-mails. Chacun est réel, et aucun ne change la réponse à "qui a le droit d'appeler qui sur le chemin de la commande". Ils vont sur leur propre diagramme, quand quelqu'un aura une question à leur sujet.

C'est le diagramme que personne ne dessine avant le premier incident, et celui qui répond aux questions que les deux autres ne peuvent pas : qu'est-ce qui est joignable depuis internet, qu'est-ce qui parle à la base, et où se situe la frontière avec un tiers. L'API Stripe est dessinée comme un noeud externe précisément parce qu'elle n'est pas la vôtre : la boîte rappelle que sa disponibilité est une dépendance que vous ne contrôlez pas.

C'est aussi le seul des trois qui se périme un mardi ordinaire. Le modèle de domaine traverse un changement de plateforme intact, et la vue composants aussi ; le diagramme de déploiement est invalidé par une migration de cluster. Cette asymétrie est une bonne raison de le garder à part plutôt que de replier "tourne sur Kubernetes" dans les boîtes de composants.

La notation derrière le diagramme du milieu, avec cinq autres topologies, est dans les exemples de diagrammes de composants. Pour produire un premier jet de l'un des trois à partir d'une description plutôt qu'à la main, voyez générer de l'UML avec l'IA.