E-Commerce-Architektur, modelliert

Ein Shop ist das Beispiel, nach dem alle greifen, und der Grund, warum die meisten Shop-Diagramme nutzlos sind, ist, dass sie ein einziges Bild sein wollen. Das Vokabular, die Dienstgrenzen und die Maschinen sind drei verschiedene Themen, und eine Zeichnung, die sie mischt, beantwortet keines davon - es ist das Diagramm mit einer Order-Klasse, einem Kubernetes-Logo und einer Queue auf derselben Fläche.

Nach Frage getrennt wird jede prüfbar:

1. Was sind die Substantive? Ein Klassendiagramm der Domäne. Was eine Bestellung ist, woraus sie besteht, ohne was sie nicht existieren darf.
2. Wer darf wen aufrufen? Ein Komponentendiagramm der Dienste und der Verträge zwischen ihnen.
3. Wo läuft es? Ein Verteilungsdiagramm der Knoten und der Artefakte darauf.

Nichts davon ist ein Queue-Diagramm, ein Sequenzdiagramm oder ein Infrastructure-as-Code-Listing, und das mit Absicht. Die gibt es und sie sind nützlich; sie sind auch der Ort, an dem ein Dokumentationssatz stirbt, wenn die ersten drei nicht stimmen.

Das ist das Diagramm, das das Vokabular festlegt, und beim Vokabular gehen Shops zuerst schief. Ist ein "Warenkorb" eine noch nicht aufgegebene Order oder etwas anderes? Hält eine OrderLine den Preis zum Kaufzeitpunkt, oder liest sie ihn vom Product? Die zweite Frage beantwortet die Abbildung - unitPrice wohnt auf der Position - und dieses eine Attribut ist der Unterschied zwischen einem Shop, dessen alte Rechnungen nach einer Preisänderung richtig bleiben, und einem, dessen es nicht tun.

Die Abbildung oben in diesem Artikel. Zwei Clients, ein Bestelldienst und zwei Verträge, von denen er abhängt - Bestand und Zahlung. Lesen Sie es, indem Sie einen Kasten zuhalten: halten Sie den Bestelldienst zu, und übrig bleiben IOrders, IStock und IPayment - genau die Spezifikation, die ein Ersatz erfüllen müsste.

Der Adapter ist das nachahmenswerte Stück. IPaymentist ein Vertrag, der dem Shop gehört; der Stripe-Adapter realisiert ihn. Nichts im Bestelldienst nennt einen Anbieter, also hat "was würde ein Wechsel zu Adyen kosten?" eine sichtbare Antwort - ein Kasten und was auch immer der Adapter durchgelassen hat. Andersherum gezeichnet, mit dem Bestelldienst direkt von einer Stripe-Komponente abhängig, braucht dieselbe Frage eine Codesuche.

Was bewusst fehlt: der Warenkorb, der Suchindex, die Empfehlungsmaschine, der E-Mail-Versand. Jedes davon ist real, und keines ändert die Antwort auf "wer darf wen im Checkout-Pfad aufrufen". Sie kommen auf ihr eigenes Diagramm, wenn jemand eine Frage zu ihnen hat.

Das ist das Diagramm, das niemand zeichnet, bis der erste Vorfall kommt, und das, welches Fragen beantwortet, die die anderen zwei nicht können: was ist aus dem Internet erreichbar, was spricht mit der Datenbank, und wo sitzt die Grenze zu einem Dritten. Die Stripe-API ist genau deshalb als externer Knoten gezeichnet, weil sie nicht Ihnen gehört - der Kasten erinnert daran, dass ihre Verfügbarkeit eine Abhängigkeit ist, die Sie nicht kontrollieren.

Es ist auch das einzige der drei, das an einem normalen Dienstag veraltet. Das Domänenmodell übersteht eine Re-Plattformierung unberührt und die Komponentensicht ebenso; das Verteilungsdiagramm wird von einer Cluster-Migration entwertet. Diese Asymmetrie ist ein guter Grund, es getrennt zu halten, statt "läuft auf Kubernetes" in die Komponentenkästen zu falten.

Die Notation hinter dem mittleren Diagramm steht mit fünf weiteren Topologien in den Beispielen für Komponentendiagramme. Um von einer Beschreibung statt von Hand einen ersten Entwurf eines der drei zu bekommen, siehe UML mit KI generieren.