Dependencies are backwards and that's a Good Thing

Here is a diagram, where B depends on A.

Does it look weird to you that the arrow above goes right to left? Most people do not draw dependencies but information flow and that goes in the reverse direction:

Information flows from A to B (because B depends on A).

Do not interpret that as UML though. In a UML class diagram this would be a directed association and mean that class A references class B somehow.

Such dependencies might seem "backwards" but there is logical argument for them. Consider how you create an information flow diagram, like the one above:

1. Create node A.
2. Create node B.
3. Update node A to reference node B.

For contrast, here is the dependency:

1. Create node A.
2. Create node B with a reference to A.

The two-step approach is simpler.

You can only reference what already exists. A book can only cite from already existing books. A build system can only create from existing artifacts. A service can only call existing APIs.

Optionally, it also allows the nodes to be immutable and that would allow to guarantee a graph of nodes to have no cycles guaranteed by construction. That is an elegant way to ensure such a property.

This might just be a small advantage, but there is zero advantage to the information flow direction, apart from a vague feeling of forwardness. Thus, dependencies should be the default choice. Also, draw them as dashed arrows.