Why I Threw Away My Service Layer and My Code Got Simpler

Sometimes the best architecture is less architecture

The code review comment was scathing: “Where’s your service layer? This is just controllers calling repositories directly. Did you even read Clean Architecture?”

I had read it. Multiple times. I’d built systems with pristine separation — controllers, services, repositories, DTOs, entities, mappers. Beautiful layers, each with a single responsibility. And every single one of those systems was a nightmare to change.

So for this project, I tried something radical: I didn’t build a service layer. At all. Six months later, our team is shipping features faster, onboarding is easier, and bugs are down. The junior dev we hired last month is productive after two weeks. In my “clean architecture” projects, it took two months.

Here’s what I learned: the service layer isn’t solving the problem we think it is. And most of the time, we don’t actually have that problem.

The Service Layer Lie We Tell Ourselves

Let me show you what I used to build. This is from a real project I worked on (names changed):

// Controller
class UserController {
  constructor(private userService: UserService) {}…