The Runtime Theory
mediumApplicationInternals#dependency-inversion#adapter

When Should You Add an Interface Boundary?

An architecture prompt about likely changes, dependency direction, test seams, adapter costs, and unnecessary abstraction.

TRT practice prompt — not a verified question from a named employer.

The Runtime Theory Team1 min read

A strong answer

I would add an interface when it protects a meaningful boundary: a likely implementation change, a dependency that needs isolation, or a contract that clarifies responsibility between modules. The core policy should depend on the behavior it needs, while an adapter translates external or infrastructure-specific details.

I would not add an interface simply to make a class mockable or to follow a pattern by name. An abstraction adds types, indirection, and another contract to maintain. If there is one stable implementation and no likely reason to vary it, direct code may be clearer.

The boundary should not hide meaningful operational behavior. A local in-memory implementation and a remote provider may both satisfy a method signature but differ in latency, consistency, and failure. The caller needs an explicit way to handle those outcomes.

Follow-up direction

Ask which module owns the policy and which module owns the technology-specific translation, then describe a test that checks each side of the seam.

This answer walks

Practice follow-ups

  1. 01Which likely change does the boundary contain?
  2. 02What failure behavior does the interface still need to expose?
  3. 03How would you remove an abstraction that stopped paying for itself?

One dispatch a week

The trace behind each question, the tradeoff that explains it, and one technical dispatch per week — no noise.

One technical dispatch per week. No noise.

Not started

Sign in to save your learning progress.

Sign in to save