E-Commerce-Architektur, modelliert
Ein Onlineshop, dreimal gezeichnet: die Domäne, mit der er handelt, die Dienste, aus denen er besteht, und die Maschinen, auf denen er läuft. Drei Diagramme, drei verschiedene Fragen, und auf keinem etwas, das auf ein anderes gehört.
9 Min. LesezeitUML 2.5.120 von 23
01Three diagrams, three questions
A shop is the example everybody reaches for, and the reason most shop diagrams are useless is that they try to be one picture. The vocabulary, the service boundaries and the machines are three different subjects, and a drawing that mixes them answers none of them - it is the diagram with an Order class, a Kubernetes logo and a queue on the same canvas.
Split by question and each one becomes checkable:
- What are the nouns? A class diagram of the domain. What an Order is, what it is made of, what it may not exist without.
- Who may call whom? A component diagram of services and the contracts between them.
- Where does it run? A deployment diagram of nodes and the artifacts on them.
Nothing here is a queue diagram, a sequence diagram or an infrastructure-as-code listing, and that is on purpose. Those exist and are useful; they are also where a documentation set goes to die if the first three are not right.
021. The domain
This is the diagram that settles vocabulary, and vocabulary is where shops go wrong first. Is a "basket" an Order that has not been placed, or a different thing? Does an OrderLine hold the price at the time of purchase, or read it from the Product? The second question is answered on the figure - unitPrice lives on the line - and that single attribute is the difference between a shop whose old invoices stay correct after a price change and one whose do not.
032. The services
The figure at the top of this article. Two clients, one order service, and two contracts it depends on - stock and payment. Read it by covering a box: cover the order service and what remains is IOrders, IStock and IPayment, which is exactly the specification a replacement would have to satisfy.
The adapter is the piece worth copying. IPaymentis a contract the shop owns; the Stripe adapter realizes it. Nothing in the order service names a provider, so "what would switching to Adyen cost?" has an answer you can see - one box and whatever the adapter turns out to have leaked. Drawn the other way round, with the order service depending on a Stripe component directly, the same question needs a codebase search.
What is deliberately absent: the cart, the search index, the recommendation engine, the email sender. Each of them is real, and none of them changes the answer to "who may call whom in the checkout path". They go on their own diagram, when somebody has a question about them.
043. The deployment
This is the diagram nobody draws until the first incident, and the one that answers questions the other two cannot: what is reachable from the internet, what talks to the database, and where the boundary to a third party sits. The Stripe API is drawn as an external node precisely because it is not yours - the box is a reminder that its availability is a dependency you do not control.
It is also the only one of the three that goes out of date on a normal Tuesday. The domain model survives a re-platforming untouched and so does the component view; the deployment diagram is invalidated by a cluster migration. That asymmetry is a good reason to keep it separate rather than folding "runs on Kubernetes" into the component boxes.
In one line each
- 01Three diagrams, three questions: the nouns, the contracts, the machines.
- 02Composition versus association on Order, OrderLine and Product is the domain model's whole payload.
- 03Own the payment contract and let an adapter name the provider - that is what makes a switch costable.
- 04Cover any component: what remains must specify its replacement.
- 05Leave search, email and recommendations off the checkout diagram; they answer a different question.
- 06Only the deployment view goes stale on a re-platforming, which is why it is its own picture.
The notation behind the middle diagram, with five more topologies, is in component diagram examples. To produce a first draft of any of the three from a description rather than by hand, see generating UML with AI.
05Häufige Fragen
Welche Diagramme braucht die Dokumentation eines Onlineshops?
Drei decken fast jedes Gespräch ab: ein Klassendiagramm für das Domänenvokabular, ein Komponentendiagramm dafür, welcher Dienst welchen Vertrag aufrufen darf, und ein Verteilungsdiagramm dafür, wo alles läuft. Ein Sequenzdiagramm nur für die ein, zwei wirklich strittigen Abläufe - meist Checkout und Erstattung.
Wie modelliert man Zahlungsanbieter, ohne das Diagramm an einen zu binden?
Zeichnen Sie den Vertrag, nicht den Anbieter. Eine IPayment-Schnittstelle mit einem Stripe-Adapter, der sie realisiert, sagt, dass der Shop von der Fähigkeit abhängt und nicht von der Marke - das ist zutreffender und genau das, was man prüfen können will, wenn ein Anbieterwechsel vorgeschlagen wird.
Sollte der Warenkorb ein eigener Dienst sein?
Im Diagramm ist das eine Entscheidung, keine Tatsache - zeichnen Sie es so, wie Ihr System tatsächlich arbeitet. Ein Warenkorb im Frontend ist Client-Sache und braucht keinen Kasten; einer, der geräteübergreifend überlebt, ist Zustand mit einem Eigentümer und bekommt eine Komponente samt Vertrag wie alles andere.
Wohin gehört die Datenbank im Architekturdiagramm?
Ins Verteilungsdiagramm als Knoten, und ins Komponentendiagramm nur als der Adapter davor. Diese Trennung hält die Komponentensicht bei den Verträgen, von denen Ihr Code abhängt, und lässt die Frage, welche Postgres-Version wo läuft, dem einen Diagramm, das von Maschinen handelt.
Passend dazu