Anti Patterns and Architecture Theater

Anti-Patterns & Architecture Theater Avoid controller business logic, blind Prisma patches, transaction-everywhere, and premature layers

Phase 14 - Service & Business Logic Architecture Volume 04 - Professional Backend

Architecture milestone

Simple architecture

v

Pressure appears

v

Add only needed structure

Phase 14 turns CRUD-oriented service methods into explicit application rules and workflows while keeping infrastructure simple.

Common business-layer anti-patterns The fastest way to understand the service layer is to see what happens when responsibilities leak.

Anti-pattern 1 - Controller performs database queries
@Patch(":id")
async update(...) {
const task = await this.prisma.task.findUnique(...);
// business checks here
return this.prisma.task.update(...);
}

This couples HTTP handling directly to persistence and makes the use case harder to reuse.

Anti-pattern 2 - Prisma update object becomes the business model return prisma.task.update({ where: { id }, data: input, // every valid field is treated as a legal business transition });

Request-shape validity does not mean every state transition is allowed.

Anti-pattern 3 - Error filter decides business meaning Phase 13 already established that the global filter formats errors. It should not infer Task workflow rules from URLs or Prisma codes.

Anti-pattern 4 - transaction everywhere Wrapping every single Prisma operation in $transaction adds complexity without improving atomicity. One database write already succeeds or fails atomically.

Anti-pattern 5 - Clean Architecture cosplay TaskController -> TaskUseCaseFacade -> TaskApplicationService -> TaskDomainService -> TaskRepositoryInterface -> PrismaTaskRepository -> TaskMapper -> Prisma

More layers are not automatically more professional

Use layers because they isolate a real kind of change or complexity. At TaskFlow's current scale, Controller -> TasksService -> PrismaService is still an excellent architecture.

Anti-pattern 6 - service knows HTTP framework details TasksService should throw meaningful application exceptions, not manipulate Fastify Reply or manually construct transport responses. That keeps business behavior reusable outside HTTP.