Príklady diagramov komponentov

Every diagram below uses the same three marks, and if you can read them you can read all five: a component is a box with the plug icon, an «interface» is a box naming a contract, and the arrows say which side of that contract each component is on. A dashed arrow with a hollow triangle means I implement this. A plain dashed arrow means I need this. The full set is in component diagram symbols, and the reasoning behind the notation is in the component diagram guide.

They are ordered by how often the shape turns up rather than by complexity. Each one names the question it settles, because a component diagram that settles nothing is the most common kind and the least useful: five boxes, five arrows, and no statement anybody could disagree with.

The figure at the top of this article. A web storefront and a mobile app both need product data; one catalogue service provides it. The interface is drawn once, between them.

That single box is the entire point of the example. Before it existed, the two clients had two different ideas of what "the catalogue" returns, and the difference lived in whichever one was written second. Naming ICatalog forces the question of what the contract actually is, and once it is named, a change to it is visibly a change to two consumers rather than an edit to one service.

Read the arrows and notice what the Ordering core does not touch. It does not depend on HTTP and it does not depend on PostgreSQL. It realizes one contract and requires another, and both of those are boxes it could have been handed by anybody.

This is the shape people mean by hexagonal architecture, ports and adapters, or clean architecture, and a component diagram is the cheapest way to check whether a codebase actually has it. If the core box has an arrow pointing at a database component rather than at an interface, the pattern is aspirational: something in the middle imports the driver.

This is the diagram to draw before a replacement, not after. The claim it makes is precise and testable: everything the order service needs from billing is in IBilling, so a second implementation of that interface can be switched in without the order service changing.

It is also the fastest way to find out that the claim is false. If somebody says "the new service cannot do statement PDFs", then statement PDFs were part of the contract and are missing from the interface, and the diagram was wrong before the migration was. That conversation costs ten minutes at a whiteboard and three months in production.

Once the old implementation is gone, delete it from the diagram. A component diagram that still shows the mainframe two years after it was switched off is the reason people stop trusting the diagrams.

Topologically this is example three with a third implementation added, and that similarity is worth sitting with: replaceability and extensibility are the same drawing. What differs is intent. In a migration the extra realization is temporary; in a plugin architecture it is the product.

The reading technique that pays here is to cover the right-hand column with your hand. What remains - the host and IExporter- is everything a fourth exporter author needs to know. If the answer to "can I write my own exporter?" requires reading the host's source, the interface is under-specified and the diagram has just told you so.

Two services, each realizing a contract the other requires. Nothing here is illegal UML and nothing on the diagram is wrong - the drawing is an accurate picture of a system that is going to be difficult, which is precisely what you want a diagram to be able to say.

A cycle between components means neither can be understood alone: no independent deployment, no test in isolation without a stub of the other, and a replacement of either has to satisfy a contract the other one is simultaneously depending on. On a class diagram a cycle is a smell; between deployable units it is a schedule risk.

The usual fixes are visible on the same picture. Move what shipping needs from IOrders into an event the orders service publishes, so the arrow becomes one-way. Or extract the shared part into a third component both depend on, which turns the cycle into a fan-in and puts you back at example one.

To draw one of these against your own system, the step-by-step version is in how to draw a component diagram. For where these components run rather than what they promise each other, that is a deployment diagram.