Forem: André Luiz Lunelli

DRY vs RUG — When Repeating Code Is Actually the Better Design

André Luiz Lunelli — Tue, 10 Mar 2026 16:00:00 +0000

TL;DR

DRY is great when duplication creates maintenance risk. Like duplicating a domain logic, like a discount.

But sometimes repetition is the better design.

A useful mental model is RUG — Repeat Until Good.

Instead of prematurely extracting abstractions, allow small duplication until the design becomes obvious.

Blindly chasing DRY can lead to:

Fragile abstractions.
Hidden intent.
Tight coupling between unrelated parts of the system.

Sometimes, explicit repetition makes the code clearer and more resilient.

Read the Full Thing

DRY — Don't Repeat Yourself — is one of the most widely taught principles in software engineering.

And for good reason.

When the same logic is duplicated in multiple places, changing behavior becomes risky. One fix may require updates across several locations, increasing the chance of bugs and inconsistencies. That’s where DRY shines.

But there's a less discussed idea that appears in some engineering discussions:

RUG — Repeat Until Good.

It’s not a formally established principle like DRY, and you won’t find tons of articles about it. But the idea is simple:

Sometimes repetition is the safest way to let a design evolve.

Instead of abstracting too early, you allow the code to repeat until the correct abstraction naturally emerges.

The risk of blindly applying DRY

When we try too hard to eliminate duplication, we often end up creating fragile abstractions.

You may have seen nested method calls like this:

Controller
  → Service
      → Manager
          → Helper
              → Interface

Now imagine trying to assemble all the parts in order to understand a simple behavior. And to be honest, frequently when I'm making maintenance in legacy codebases, I often find myself asking Claude to explain the whole feature—what it’s about—because the code is more of a puzzle than explicit logic.

Sometimes those abstractions exist only to remove a few repeated lines of code.

They don’t add real value to the product.

They just hide the intent somewhere else.

And in many cases, they introduce something worse:

Tight coupling.

Suddenly, multiple parts of the system depend on the same abstraction — and changing it can create unintended side effects.

When repetition is actually safer

A good example appears in request validation.

In Laravel, it's common to use Form Request classes.

class StoreUserRequest extends FormRequest
{
    public function rules(): array
    {
        return [
            'email' => ['required', 'email'],
            'birth_date' => ['required', 'date', 'before:today'],
        ];
    }
}

Now imagine you have another request with a very similar validation.

class UpdateUserProfileRequest extends FormRequest
{
    public function rules(): array
    {
        return [
            'email' => ['required', 'email'],
            'birth_date' => ['required', 'date', 'before:today'],
        ];
    }
}

Yes — there is duplication.

But extracting a shared abstraction for this might actually increase coupling between unrelated requests.

If you change validation in one request, you probably don’t want to affect all the others.

Keeping them separate means:

Changes stay localized
Behavior is explicit
The system becomes more resilient

Sometimes repetition protects isolation.

A practical rule of thumb

Use DRY when dealing with domain or business logic.

Use RUG in scaffolding code when repetition:

Keeps logic explicit
Avoids unnecessary coupling
Makes the code easier to understand

The key is recognizing that not all duplication is bad.

Sometimes the best abstraction is the one that doesn’t exist yet.

To finish this thought, I always remember an idea that stuck with me while I was growing as a decision-maker in my roles:

Good code is the code that is easy to throw away.

Not because we want to delete it. But when code is simple, explicit, and loosely coupled, it becomes safe to change, safe to replace, and safe to evolve.

Why Passing Eloquent Models to Queued Jobs Can Be Problematic

André Luiz Lunelli — Fri, 06 Mar 2026 01:35:52 +0000

TL;DR

Avoid dispatching jobs with full Eloquent models.

SendOrderConfirmation::dispatch($user);

Instead, pass only what the job actually needs.

SendOrderConfirmation::dispatch($user->id);

Passing models can:

Increase queue payload size
Break jobs after deployments
Expose sensitive data in logs or failed jobs

Smaller payloads make your system more resilient, predictable, and safer.

Read the Full Thing

I still see this pattern frequently in PRs. And to be clear — I'm not trying to turn this into a big issue. It works.

But it can also introduce surprisingly large problems for such a small decision.

1. Your queue payload may grow unexpectedly
And most of the time, this isn't intentional. In larger systems, it's easy to forget that a model may already have relationships loaded. Sometimes those relationships were loaded earlier in the request lifecycle — possibly by code you didn't even write.

$user->load('products');

If that user has 50 products loaded, those relationships may end up serialized as part of the job payload when the job is pushed to the queue — whether you're using Amazon SQS, Redis.

Now the queue message contains far more data than the job actually needs.

In many cases, the job only requires something simple like:

the user id
the order id

Nothing else.

2. Deployments can break queued jobs
Now imagine this sequence:

A job is dispatched with a serialized model
A new deployment happens
The model structure changes
The job retries and attempts to deserialize the old payload

Suddenly, the worker cannot reconstruct the object correctly.

This creates fragile jobs and reduces fault tolerance.
Jobs should remain as independent and version-resilient as possible.

3. Sensitive data may end up in queue logs
When a model is serialized, its attributes may appear inside the queue payload.

That means information could show up in:

failed job logs
queue dashboards (like Horizon)
debugging tools
dead-letter queues

In regulated environments like healthcare or finance, this can become a compliance risk.

Even if passwords are hashed, other fields may still contain personally identifiable information (PII).

Minimizing the data you send to queues helps protect your system.

A safer pattern

Dispatch jobs with only the identifiers they need:

SendOrderConfirmation::dispatch($user->id);

Then resolve the model inside the job:

public function handle(): void
{
    $user = User::findOrFail($this->userId);
}

This keeps your jobs:

lighter
safer
easier to retry
more resilient to change

Sometimes the best PR feedback is simply:

“Do we really need to pass the whole model here?”

Most of the time, the answer is no.

Stop Mixing UI Components With Business Logic

André Luiz Lunelli — Wed, 04 Mar 2026 19:58:54 +0000

TL;DR

Separate your frontend components into two clear groups:

components/
│
├── app/ → // components that encapsulate business logic
│   ├── AppliesCoupons.vue
│   └── SearchUserInput.vue
│
└── ui/  → // purely visual components
    ├── Badge.vue
    ├── Button.vue
    └── Input.vue

This fosters a clean architecture, and it works whether you're using Blade, Livewire, Vue, React, or anything else.

Read the Full Thing

At some point, I noticed something was bothering me in my projects.

I was already using components everywhere. Buttons were components. Inputs were components. Modals were components.
Don't get me wrong, that part was good.

But I often found myself doing things like building a registration page where I had an input field that checked whether the email already existed in the database.

So I would create something like:

RegisterEmailInput.vue

Inside it, I'll add:

Debounce logic
An API call
Domain validation
Error interpretation

This would definitely work. But something felt off.

Was that really just an "input"? Or was it part of the application logic?

The Problem

When everything lives inside the same components/ folder, you start losing clarity.

A Button.vue and a SearchUserInput.vue don’t belong to the same category of responsibility.

One is visual. The other represents domain behavior.

That’s when I made a structural change to the structure I use now:

components/
│
├── app/
│   ├── AppliesCoupons.vue
│   └── SearchUserInput.vue
│
└── ui/
    ├── Badge.vue
    ├── Button.vue
    └── Input.vue

ui/

Purely visual
Reusable anywhere
No API calls
No domain knowledge

You could copy them to another project and they would still work.

app/

Talks to APIs
Applies business rules
Knows about the domain
Controls behavior

These components are not just UI.
They represent application logic.

Why This Matters

This separation changes how you think.

Instead of asking:

“Where do I put this component?”

You start asking:

“Is this visual, or does it represent domain behavior?”

That question alone improves architectural clarity.

It also makes:

Refactoring easier
Testing more predictable
Responsibilities clearer
Code reviews more objective
The codebase easier to navigate
Feature responsibilities easier to understand

And the best part?

This approach works in: Laravel (Blade / Livewire), Vue, React or any other component-based frontend. Because this isn’t about framework.

Keep Code References Out of Your Migrations

André Luiz Lunelli — Fri, 30 Jan 2026 15:30:28 +0000

TL;DR

Long story short, don't reference your business layer within migration files.

Migrations should be immutable snapshots of your database history, never dependent on evolving application code.

❌ Bad (breaks if enum class changes or is removed)

$table->enum('role', array_column(Can::cases(), 'value'));

✅ Good (enum values explicitly defined, stable and independent)

$table->enum('role', ['access_admin', 'can_impersonate']);

Read the Full Thing

Often, when we define enum values in a model, like a role property or a status for something, and we want to provide an input where the user can choose an option, it's a good practice to reference the enum class by using foreach logic to iterate over these values to display them for the user.

Something like:

// app/Enums/Role.php
enum Role: string
{
    case Admin = 'access_admin';
    case Moderator = 'can_impersonate';
    case User = 'regular_user';
}

{{-- resources/views/users/form.blade.php --}}
<select name="role">
    @foreach(Role::cases() as $role)
        <option value="{{ $role->value }}">
            {{ str_replace('_', ' ', ucfirst($role->value)) }}
        </option>
    @endforeach
</select>

That's a good practice, isn't it? Can you imagine if, instead of iterating over an enum to get those values, you chose to rewrite the same occurrences in the whole project (backend, frontend)? Not cool.

Why Migrations Are Different

Migrations aren't like your application code - they're historical records of how your database evolved over time. Once a migration runs in production, it should never need to change.

Migrations should be your database changelog

They document every schema change over time
With dynamic references, you lose that documentation
You can't look at migrations and understand how the schema evolved

Fragility

Today: Your Role enum has admin and user values
Migration runs: Creates column with those values, everything ok ✓
6 months later: You rename Role enum to UserRole, or delete it entirely
New developer runs migrations: 💥 Fatal error - Role class not found

As a result

Forces us to edit old migrations
Creates extra work
Increases the risk of errors

Bonus

Also, I'd avoid using foreignIdFor() because it couples the migration directly to a model. If that model is deleted or renamed, the migration becomes invalid.

Well, that's all, folks.

Cleaning up dates within Laravel Blade

André Luiz Lunelli — Fri, 20 Jun 2025 02:57:23 +0000

TL;DR

So basically, you can use a Custom Echo Handler to apply the same datetime format when printing Carbon instances within blade files.

Instead of have something like this:

<tr>
    <td>{{ $user->created_at->format('m/d/Y H:i') }}</td>
    <td>{{ $user->updated_at->format('m/d/Y H:i') }}</td>
    <td>{{ $user->deleted_at->format('m/d/Y H:i') }}</td>
    <td>{{ $user->email_verified_at->format('m/d/Y H:i') }}</td>
</tr>

You can have this:

<tr>
    <td>{{ $user->created_at }}</td>
    <td>{{ $user->updated_at }}</td>
    <td>{{ $user->deleted_at }}</td>
    <td>{{ $user->email_verified_at }}</td>
</tr>

By doing this:

// AppServiceProvider.php

use Illuminate\Support\Carbon;
use Illuminate\Support\Facades\Blade;

public function boot(): void
{
    Blade::stringable(function (Carbon $carbon) {
        return $carbon->format('m/d/Y H:i');
    });
}

And that's it.

Read the Full Thing

I went to review some pull requests, and there was one that had many carbon dates repeating the output format to display in the right US format.

There isn't a real problem doing it that way; it's very straightforward. But it's boring. Can it be simpler? Let's give it a try.

First, I tried to create a class that would inherit from the Carbon instance and override the __toString method. You can do it in the DateFactory by informing which class you want to use as concrete.

\Illuminate\Support\DateFactory::useClass(MyCarbonDate::class);

I didn't like the idea of ending with a new class just to prevent me from typing the format of the datetimes. Seems like overengineering, so I decided to move on.

Also, sniffing a little bit, I found that you can set a "toString" strategy using the Date facade:

\Illuminate\Support\Facades\Date::setToStringFormat('m/d/Y H:i')

But who can say that it won't break anything else in the future, like, I don't know, some inner Laravel hydration thing.

I need a simpler solution and don't want to reinvent the wheel. So I remember about Laravel Eloquent Casting and I saw the Date Casting. That is what I want!

Eventually the code didn't work, and I went back to the docs to figure it why, and that was the reason:

This format will be used when the model is serialized to an array or JSON

In summary, this is going to work through API Resources.

Ok, maybe I'm overthinking this. Forget about it, let's move on. I started to do another daily task. But my brain still didn't give up; I was intrigued. How it's possible that anyone wanted to do this in their blade files?

Ok, let's take only 5 minutes to look again at the docs, maybe I miss something. And I did :D

At the blade section I could find the Custom Echo Handlers

This closure should type-hint the type of object that it is responsible for rendering.

But wait, it isn't working. Well, clearing the cache sometimes solves things. So I did:

php artisan view:clear

And it works!

It's nice to only type the variable that you wanna print, without always having to type the format every time, and with a chance to misspell the format. Additionally, if in the future I support another locale, I could even provide different formats based on this, something like:

Blade::stringable(function (Carbon $carbon) {
    if (app()->getLocale() !== 'en') {
        return $carbon->locale(app()->getLocale())->format('Y-m-d H:i');
    }

    return $carbon->format('m/d/Y H:i');
});

That's all, folks.

whoami

André Luiz Lunelli — Mon, 26 May 2025 00:42:41 +0000

So, it's been a while since I wanna write/share some nice tips and I thought:

why don't I start talking about myself?

Uh, ok, I'm not the kind who enjoys the exposure, but who knows what can happen when I start? At least I can see two good things from this start:

I'm pushing to write/think in English, which isn't my mother language.
When someone asks me about it, I can send it back and save time.

Let's start

I'm André Luiz Lunelli, I'm 33 years old, I'm Brazilian, and have a bachelor’s degree in computer science from the Regional University of Blumenau. I've been a software developer since 2012, but I've been acting as tech lead since 2023. In 2022, I was promoted to husband and in 2024 to father.

Guiding principles:

Simplicity over Complexity
Composition over Inheritance
YAGNI