Concept questionMedium~7 minApplication Architecture Essentials / 1 of 15

Interview question

A service validates an order, calculates prices, writes to the database, sends email, and records analytics. How would you apply the single-responsibility principle without creating dozens of tiny classes?

Single responsibility and cohesive boundaries in real code

Applies single responsibility to reasons for change, cohesive behavior, and maintainable service boundaries instead of counting methods.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would separate responsibilities by cohesive reasons for change, not by method count. Order pricing and validation belong with business rules, persistence belongs behind the data boundary, and email or analytics are external effects. An application service can still coordinate those collaborators because orchestration is one clear responsibility. I would keep behavior together when it changes for the same business reason.

Full answer below

Practice focus

Reasons for change, cohesion, orchestration, domain behavior, side-effect boundaries, and avoiding class-per-method fragmentation.

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
Single responsibility is useful when it reveals unrelated reasons for change. Applied mechanically, it can replace one oversized class with a maze of tiny types that is harder to understand.
I would separate responsibilities by cohesive reasons for change, not by method count. Order pricing and validation belong with business rules, persistence belongs behind the data boundary, and email or analytics are external effects. An application service can still coordinate those collaborators because orchestration is one clear responsibility. I would keep behavior together when it changes for the same business reason.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would first identify which rules must stay consistent in one operation. The order model or a pricing policy can calculate totals and reject invalid transitions. A repository or DbContext persists the result, while notification and analytics ports describe effects outside the core decision. The application service reads like the use case: load, decide, save, then trigger or enqueue effects. That gives focused tests without forcing every three lines into a new abstraction.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would also separate transactional work from effects that can fail independently. Saving an order and publishing its event may need an outbox, while email delivery can retry without repeating the order transition. I would watch the direction of change: if every pricing rule requires edits to the coordinator, the boundary is still wrong; if tracing one request requires opening twenty trivial files, it is over-split. Cohesion, failure ownership, and change history are better evidence than class size alone. I would refactor incrementally around repeated change pressure rather than designing a complete taxonomy of responsibilities in advance.

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

Defining one responsibility as one method.
Moving every private method into a separate service.
Leaving business decisions inside the controller.
Separating code without clarifying transaction or failure boundaries.

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

Details

The use case is spread across many pass-through classes.
A pricing change still touches persistence and notification code.
External effects run before the business change is durable.
No type clearly owns the business invariant.

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.

When is a larger cohesive class acceptable?
What should the application service own?
How would an outbox change this boundary?

Continue the section

Next in Application Architecture Essentials: Open-closed with strategies

Step 2 of 15

Open-closed principle with strategies instead of growing flags

Opening drill

Concept questionMedium~7 minApplication Architecture Essentials / 1 of 15

Interview question

A service validates an order, calculates prices, writes to the database, sends email, and records analytics. How would you apply the single-responsibility principle without creating dozens of tiny classes?

Single responsibility and cohesive boundaries in real code

Applies single responsibility to reasons for change, cohesive behavior, and maintainable service boundaries instead of counting methods.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Reasons for change, cohesion, orchestration, domain behavior, side-effect boundaries, and avoiding class-per-method fragmentation.

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
Single responsibility is useful when it reveals unrelated reasons for change. Applied mechanically, it can replace one oversized class with a maze of tiny types that is harder to understand.
I would separate responsibilities by cohesive reasons for change, not by method count. Order pricing and validation belong with business rules, persistence belongs behind the data boundary, and email or analytics are external effects. An application service can still coordinate those collaborators because orchestration is one clear responsibility. I would keep behavior together when it changes for the same business reason.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would first identify which rules must stay consistent in one operation. The order model or a pricing policy can calculate totals and reject invalid transitions. A repository or DbContext persists the result, while notification and analytics ports describe effects outside the core decision. The application service reads like the use case: load, decide, save, then trigger or enqueue effects. That gives focused tests without forcing every three lines into a new abstraction.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would also separate transactional work from effects that can fail independently. Saving an order and publishing its event may need an outbox, while email delivery can retry without repeating the order transition. I would watch the direction of change: if every pricing rule requires edits to the coordinator, the boundary is still wrong; if tracing one request requires opening twenty trivial files, it is over-split. Cohesion, failure ownership, and change history are better evidence than class size alone. I would refactor incrementally around repeated change pressure rather than designing a complete taxonomy of responsibilities in advance.

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

Defining one responsibility as one method.
Moving every private method into a separate service.
Leaving business decisions inside the controller.
Separating code without clarifying transaction or failure boundaries.

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

Details

The use case is spread across many pass-through classes.
A pricing change still touches persistence and notification code.
External effects run before the business change is durable.
No type clearly owns the business invariant.

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.

When is a larger cohesive class acceptable?
What should the application service own?
How would an outbox change this boundary?

Continue the section

Next in Application Architecture Essentials: Open-closed with strategies

Step 2 of 15

Open-closed principle with strategies instead of growing flags

A service validates an order, calculates prices, writes to the database, sends email, and records analytics. How would you apply the single-responsibility principle without creating dozens of tiny classes?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

A service validates an order, calculates prices, writes to the database, sends email, and records analytics. How would you apply the single-responsibility principle without creating dozens of tiny classes?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section