Boilerplate is not evil

You've probably heard: "Why so much code for a simple task?", "Why can't you just write it?", "This architecture of yours only complicates things." This is usually said when someone first encounters boilerplate: DTOs, mappers, layers, model separation. And I understand them. Because I had the same reaction.

When I first started working with a stricter architecture, it was frustrating. You add one field and change several classes: DTO, mappers, and a couple more layers. And it feels like: "I'm writing 3 times more code for the same task." And in the short term, that's true.

Especially if you have previously worked with, for example, Active Record, where the model equals everything, logic is right inside, data, validation, behavior — all in one place. You just write and everything works, quickly, conveniently, without any extra hassle. The problem doesn't start immediately. It begins when the system grows.

Typical scenario. First, one model, a bit of logic, everything is clear. Then observers are added, events are added, checks are added, business logic starts to spread out. And at some point, you no longer understand where everything is happening.

The most painful moment is changes. For example, you had one data source (a local database). Then an external API or another type of storage appeared, or you need to change the way you retrieve data. And suddenly you need to change everything: controllers, models, business logic. Because everything is directly connected.

And this is where it becomes clear why boilerplate is needed. When you have a structure, the domain is separated, the infrastructure is isolated, there are models for each layer, and there is mapping, changing the data source does not break the system. You only change the infrastructure layer. The rest remains untouched. And this is the key idea, boilerplate is not about "writing more code," boilerplate is about "limiting the area of changes".

Now about the level of abstraction. Many perceive it as "complication." In practice, it's just a different level of work. You stop thinking "how to save to the database," and start thinking "what is an entity," "what are its rules," "how should the system behave". Infrastructure takes a back seat, and system behavior comes to the forefront. Yes, the price for this is additional code. But this is code that makes the system predictable, simplifies changes, and reduces the number of errors in the long run.

Boilerplate is especially important in a team. Because repeatability = predictability. When the structure is the same, a new developer integrates faster, it's easier to read the code, and it's easier to do reviews. They don't think "how is everything arranged here," they already know it. And this is where a shift in thinking occurs. At first, you think "why so much template code," then you realize "it's good that it's the same everywhere." Yes, boilerplate can be partially automated through code generation, templates, and AI. And that's normal. Because its goal is to fix the structure.

And finally. Architecture is not about complication. It's about control. If you have a small project, yes, you can keep it simple. But as soon as the system starts to grow, chaos becomes more expensive than extra code. In short, without structure, you're faster at the start. With structure, you're faster in the long run. And the choice is always the same, fast now or stable later. Boilerplate is the price for stability. And if you accept this, you start writing code that lasts longer than a single feature.