Concept questionMedium~7 minApplication Architecture Essentials / 5 of 15

Interview question

How would you apply dependency inversion when an order workflow uses EF Core, a payment provider, and email?

Dependency inversion and the application composition root

Keeps business policy independent from infrastructure while centralizing concrete dependency assembly at the application edge.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

The order workflow should depend on contracts expressed in business terms, such as reserving payment or sending an order confirmation, while infrastructure implements those contracts using EF Core, an external provider, or email. The outer application composition root selects concrete implementations and their lifetimes. Dependencies point toward the policy that defines what the use case needs.

Full answer below

Practice focus

Policy versus mechanism, ports, dependency direction, dependency injection, composition roots, and abstraction ownership.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Dependency inversion keeps high-level business policy from importing low-level mechanisms. Dependency injection is one way to assemble that design, but registering every concrete class behind an interface does not create it automatically.
The order workflow should depend on contracts expressed in business terms, such as reserving payment or sending an order confirmation, while infrastructure implements those contracts using EF Core, an external provider, or email. The outer application composition root selects concrete implementations and their lifetimes. Dependencies point toward the policy that defines what the use case needs.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would keep contracts narrow and owned near the consuming application or domain code. A payment port returns a result the workflow can reason about rather than leaking an SDK response. Persistence may use a repository when that protects a domain boundary, or the application layer may use an EF Core abstraction directly when the extra port adds no value. Program.cs or a focused registration module remains the place that knows both sides and composes them.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would treat failure semantics as part of each port. Payment needs idempotency and ambiguity handling, email may be asynchronous, and persistence participates in a transaction that external calls do not. The composition root also owns decorators for telemetry, resilience, and authorization in an explicit order. I avoid service registration that scans everything and hides which implementation wins. Boundary tests prove the core code has no infrastructure references, while integration tests verify each adapter against the real protocol or an isolated substitute. The payoff is controlled change and testable policy, not interfaces as decoration.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Equating dependency inversion with using a DI container.
Defining ports from vendor SDK shapes.
Putting service resolution inside business code.
Creating repositories that only rename every DbSet method.

Red flagsCandidateSigns the design is fragileSignals that an interviewer may treat as risky.Open details

Details

Core projects reference infrastructure packages.
The selected implementation depends on registration order.
Vendor exceptions cross the policy boundary.
External side effects are treated as one database transaction.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Who owns the abstraction?
When is a repository unnecessary?
What belongs in the composition root?

Continue the section

Next in Application Architecture Essentials: DI vs service locator

Step 6 of 15

Dependency injection versus the service locator pattern

Opening drill

Concept questionMedium~7 minApplication Architecture Essentials / 5 of 15

Interview question

How would you apply dependency inversion when an order workflow uses EF Core, a payment provider, and email?

Dependency inversion and the application composition root

Keeps business policy independent from infrastructure while centralizing concrete dependency assembly at the application edge.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Policy versus mechanism, ports, dependency direction, dependency injection, composition roots, and abstraction ownership.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Dependency inversion keeps high-level business policy from importing low-level mechanisms. Dependency injection is one way to assemble that design, but registering every concrete class behind an interface does not create it automatically.
The order workflow should depend on contracts expressed in business terms, such as reserving payment or sending an order confirmation, while infrastructure implements those contracts using EF Core, an external provider, or email. The outer application composition root selects concrete implementations and their lifetimes. Dependencies point toward the policy that defines what the use case needs.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would keep contracts narrow and owned near the consuming application or domain code. A payment port returns a result the workflow can reason about rather than leaking an SDK response. Persistence may use a repository when that protects a domain boundary, or the application layer may use an EF Core abstraction directly when the extra port adds no value. Program.cs or a focused registration module remains the place that knows both sides and composes them.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would treat failure semantics as part of each port. Payment needs idempotency and ambiguity handling, email may be asynchronous, and persistence participates in a transaction that external calls do not. The composition root also owns decorators for telemetry, resilience, and authorization in an explicit order. I avoid service registration that scans everything and hides which implementation wins. Boundary tests prove the core code has no infrastructure references, while integration tests verify each adapter against the real protocol or an isolated substitute. The payoff is controlled change and testable policy, not interfaces as decoration.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Equating dependency inversion with using a DI container.
Defining ports from vendor SDK shapes.
Putting service resolution inside business code.
Creating repositories that only rename every DbSet method.

Red flagsCandidateSigns the design is fragileSignals that an interviewer may treat as risky.Open details

Details

Core projects reference infrastructure packages.
The selected implementation depends on registration order.
Vendor exceptions cross the policy boundary.
External side effects are treated as one database transaction.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Who owns the abstraction?
When is a repository unnecessary?
What belongs in the composition root?

Continue the section

Next in Application Architecture Essentials: DI vs service locator

Step 6 of 15

Dependency injection versus the service locator pattern

How would you apply dependency inversion when an order workflow uses EF Core, a payment provider, and email?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

How would you apply dependency inversion when an order workflow uses EF Core, a payment provider, and email?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section