Deployment diagram client-server

Question

I have added a little to my component diagram and you can read more about the purpose of each component in my previous question: Component diagram relationship between files

Now I'm trying to make a deployment diagram. And I had a few questions when I was building it.As far as I know, the deployment diagram does not specify code files, but only some dynamic libraries and executable files.I have specified a javascript interpreter and linked it to a business logic layer.Is this considered acceptable?

I also placed the caching component and linked it to the Data Access layer(should I host this component on another node or can I host it on a server node?)

I would also like to know if I have painted the node enough for the database servers? Or can I supplement them with something else, with some other components?

I also specified a node for a external payment system that my system will interact with. I just indicated an approximate set of components, but did not logically separate them somehow, because I have nothing to do with this system.

I would be glad to receive recommendations from you and hear comments if I did something wrong

In the bottom diagram you have Client, Server etc. in something that looks lika a class. Or maybe it's a boundary. Both would be wrong. The first for hosting components and the second to connect them with associations. — qwerty_so, Apr 03 '23 at 21:38

score 0 · Answer 1 · answered Apr 04 '23 at 21:21

The nodes are not limited to the hardware environment like Client PC or Server: you may further nest in the devices some software execution environments such as NodeJS (example).

You would then show the BLL and DAL components with their nested components within the NodeJS execution environment:

The components should be named without the filename extension, because files re represented as artefacts in deployment diagram.
You could then show the .js artefacts within the Server node (since technically those files are deployed to the server and not the NodeJS) and keep the components in NodeJS execution environment, linking both with a «manifest» dependency from the artefact to the component

score 0 · Answer 2 · answered Apr 10 '23 at 01:54

The purpose of a deployment diagram is to allow engineers to understand how your system interacts with infrastructure. It does that by explaining two crucial relationships:

How components are materialized by artifacts
Where each artifacts are deployed on nodes

You can usually also use the deployment diagram to explain which nodes need to communicate together, and what protocols they use.

Component materialization

In your diagram, components should not be in nodes. A component is a logical concept, that is used to describe the topology of your application. A node is an infrastructure concept. They cannot interact together directly, they need an intermediate which is an artifact. An artifact is a physical part of your system, that materialize (= implements) a component. Most of the time, the artifact is the binary produced by the compilation of the source code of the component. Sometimes, the mapping is not straightforward and the deployment diagram helps to explain how this mapping works.

Artifact deployments

Artifacts are physical components that are deployed (= copied / placed) on nodes. Artifacts include a description of their expected behavior understandable by the node they are deployed on. The node, which is a bag of physical resources, will execute the artifacts that are deployed on them and follow the behavior it describes. Most of the time, the node does not execute the artifact directly but relies on an execution environment: operating system, virtual machine, runtime, interpreter, ... Execution environment can nest, especially if you have a lot of virtualization: IAAS, VM, containers, kubernetes, application runtimes, ...

Deployment diagram

Here is an example of deployment diagram of your solution:

Keep in mind that there is no absolute answer regarding deployment diagrams. You can have different level of details, depending on what you want to achieve with the diagram. Here I made a focus on communication between nodes, I could have made another one with communication at artifact level, or execution environment level. Also I made a very coarse description of the component level topology for simplicity reasons.

Why node is not an artefact

Node is a specific case, because it is an interpreter. the source code is interpreted and not compiled into a binary. The source code acts as an artifact. The source code is read and executed by node just like a compiled C program would be read and executed by the operating system. This is why source code are artifacts (and not a component) and node is an execution environment (and not an artifact).

Differences with the component diagram

People may find the deployment diagram redundant with the component diagram. The deployment diagram is more recent, but also the deployment diagram serves a different purpose from the deployment diagram. The component diagram describes the logical topology of your information system. It determines the limits of responsibility regarding features and people. People reading your deployment diagrams should be able to understand what are all the contents of your deployment package, and how to deploy them on the infrastructure.