Dependencies

Dependencies are the edges in your architecture graph. They describe how applications and components rely on each other, and they are the foundation of blast radius analysis.

Dependency levels

Dependencies can be defined at two levels:

Application-to-Application — High-level relationships between systems. Useful for portfolio-level views.
Component-to-Component — Fine-grained relationships between deployable units. Essential for accurate blast radius, and the level that carries the channel & security register below.

You can model both levels simultaneously. Application-level dependencies give you a quick overview, while component-level dependencies provide precise impact analysis.

Dependency types

The dependencyType field describes what kind of interaction flows across the edge. Values are case-sensitive and serialized exactly as shown:

Type	Meaning
`Calls`	Synchronous invocation (HTTP, gRPC, direct call)
`Reads`	Reads data from the target
`Writes`	Writes data to the target
`ReadsWrites`	Both reads from and writes to the target
`Publishes`	Sends events or messages to the target (or a broker channel)
`Consumes`	Receives events or messages from the target
`PubSub`	Publish/subscribe over a broker channel
`TrafficFlow`	Network-level traffic routing
`UsesIdp`	Delegates authentication to an identity provider

Dependency modes

The mode field describes how critical the dependency is:

Mode	Meaning
`Hard`	The source cannot function without the target. Failure propagates immediately.
`Soft`	The source partially functions without the target; some features degrade.
`Async`	Asynchronous coupling. Short-term target unavailability is tolerable because of queues or buffers.
`Degraded`	The source continues operating but with reduced quality or performance.

Warning

Dependency mode directly affects blast radius results. A Hard dependency always propagates impact, while Async dependencies may not — depending on your filter settings.

Channel & security register

Component dependencies can carry the details that make each edge part of your dependency security register — a compliance artefact describing data-in-transit:

protocol — e.g. HTTPS, gRPC, AMQP.
transportEncryption — e.g. TLS 1.3, or None to flag an unencrypted hop.
endpointAuthMethod — how the caller authenticates (e.g. OAuth2, mTLS, API key).
channelType — for pub/sub edges, one of Topic, Queue or Stream, with an optional broker component.
evidence — how the edge was established: Declared, Observed or Inferred.

Tip

The security register is what lets Dependra read your dependency graph back as a data-in-transit catalogue — an ISO 27001 / NIS2-friendly artefact — rather than just a picture.

Additional attributes

required — a boolean (default true). When true, the dependency is essential for the source to operate.
propagates — whether impact traverses this edge during blast-radius computation.
timeoutMs — an optional timeout, useful for documenting SLA expectations between systems.

Best practices

Start with application-level dependencies to get a quick overview of your landscape.
Add component-level dependencies for critical paths where you need precise blast radius.
Be honest about modes — marking everything as Hard defeats the purpose of nuanced impact analysis.
Fill in the security register on external and sensitive edges — it is what turns the graph into compliance evidence.
Review regularly — dependencies change as your architecture evolves. Stale dependency data leads to misleading blast radius results.