Arquitectura de e-commerce, modelada

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:

1. 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.
2. Who may call whom? A component diagram of services and the contracts between them.
3. 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.

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.

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.

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.

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.