In creating an architecture diagram, if you will just fetch data from the database and not write to it, where should the arrow point? I was thinking, it should be bidirectional since the app request from the database and the data is returned to the app. Or it should just be from the the DB towards the app even though the database cannot make an action on its own?
AFAIK, there are no well defined rules around the way we should build our diagrams, the most important thing is to be descriptive enough to be easily understood by the people who need to read them.
It's true that the DB cannot initiate a connection on its own (it responds to requests coming from the app), but usually in an architecture diagram you want to highlight the data flow, and not necessarily the component who initiates the connection.
If the app is only writing data to the DB, I would prefer to make an arrow that points towards the DB, illustrating the direction where the data is flowing. If you're only reading, then I would make the arrow pointing towards the app (and bidirectional if you do both operations).
At the end of the day, the most important thing is to be consistent throughout the diagram. You can add a note somewhere to explicitly say the general meaning of an arrow.
I'm usually drawing arrows from the consumer to the provider, i.e. from client to server, app server to database, frontend to backend, to describe the active part of communication. It can also be communication between systems, like webshop being dependent on erp.
This describes the dependencies of the systems. So when a system is no longer depended on, it might be removed.
If an integration is done between two passive systems, I would in a detailed picture draw that as it's own box, since it is it's own system. In a high-level picture I would draw the arrow to depict data flow, since the downstream system is (technically) not dependent on the upstream system to work.
© 2022 - 2024 — McMap. All rights reserved.
