Controller vs Service Responsibilities Keep HTTP translation thin while providers execute application use cases
Phase 14 - Service & Business Logic Architecture Volume 04 - Professional Backend
v
v
v
Phase 14 turns CRUD-oriented service methods into explicit application rules and workflows while keeping infrastructure simple.
A controller translates HTTP; a service executes a use case NestJS documentation recommends that controllers handle HTTP requests and delegate more complex work to providers. TaskFlow now makes that separation concrete: controllers translate transport concerns; TasksService owns Task use cases and rules.
route + HTTP method business workflow
path/body extraction domain invariants
validation pipe invocation cross-model checks
status semantics orchestration of reads/writes
delegate to provider meaningful application exceptions
Thin does not mean useless A controller still has an important responsibility: it defines the transport contract. Thin means it does not decide whether DONE can return to TODO, whether an assignee belongs to a workspace, or how completedAt should change.
@Patch(":id")
update(
@Param("id", { schema: taskIdSchema }) id: string,
@Body(new StandardSchemaValidationPipe(updateTaskSchema)) input: UpdateTaskDto,
) {
return this.tasksService.update(id, input);
}v
v
v
The service is where transport-independent application meaning lives.
Service layer is not a pass-through layer If TasksService only forwards every input directly to prisma.task.update(), it is not protecting business behavior. As rules appear, the service should coordinate the use case before the write.
Putting transition tables or membership queries into TasksController makes the same rules difficult to reuse from jobs, tests, CLI tools, or future non-HTTP entry points.
A service can also grow too large. Do not respond by extracting arbitrary classes early. First group methods by use case and keep private rule helpers local. Extract only when a rule becomes independently complex, reused, or deserves its own clear responsibility.
NestJS structure becomes valuable when the request pipeline and responsibility of controllers, services, guards, pipes, and providers are explicit rather than magical.
Restate the goal of “Controller vs Service Responsibilities” as one observable behavior. Write the success signal before touching code.
Trace the boundary map: HTTP request → Fastify adapter → Nest pipeline → controller → service → response. Mark the one boundary this lesson changes.
Inspect the current repository state and record the exact files, route, table, or runtime involved. Avoid creating an abstraction before you can name the existing owner.
Implement the smallest vertical slice. Add one coherent change, run the narrowest verification command, and read the output before continuing.
Connect the slice to TaskFlow’s phase artifact: Refactored task service with explicit policies/invariants and thin controllers.. Verify behavior from the outside as a user or API client would.
Create one controlled failure that is safe to reproduce. Predict the symptom first, capture evidence, locate the earliest broken boundary, then fix only that cause.
Close the reference and rebuild or explain the core change from memory. Record what you would monitor or test before trusting the same change in production.
@Controller("tasks")
export class TasksController {
constructor(private readonly tasks: TasksService) {}
@Get()
findAll() {
return this.tasks.findAll();
}
}Do not copy this as a finished answer. Predict what each boundary does, type the smallest useful slice, run it, then compare the result with your prediction.
Read the constructor index in the error, then check provider registration, module imports, and exports in that order.
Confirm method/path, controller registration, global prefix, and guard/pipe behavior using request logs.
Without copying the final source, create a second small scenario that applies “Controller vs Service Responsibilities” to a different TaskFlow resource or input. Write the acceptance criteria first, implement it, and provide the evidence that each criterion is satisfied.
Choose one endpoint with mixed concerns and list every responsibility it currently performs.
Use the smallest change that demonstrates this lesson. Stop after it works and capture evidence.God services with hundreds of unrelated lines
Predict the symptom before causing the failure. Then locate the earliest boundary where reality diverges from expectation.Why does this responsibility live here, what input does it trust, what output proves success, and what would go wrong if another layer owned it?
If your explanation is vague, repeat the boundary trace before moving on.Close the reference. Reproduce the core idea from memory or explain the exact request/data flow aloud. Then check your diff or notes for accidental shortcuts that bypass validation, authorization, error handling, or verification earned in earlier phases.