Hey devs, nos ponemos técnicos y vamos directo al corazón de muchos de los problemas de código allá afuera. Este tema lo enseño en un curso de código limpio que dicto, y considero que es tan importante que quise hacerle su propio artículo, así que empecemos!

Uno de los code smells más comunes y a menudo invisibles en el desarrollo diario es “Primitive Obsession”.

Ocurre cuando usamos tipos primitivos (string, int, decimal, etc.) para representar conceptos del dominio que merecen una identidad propia.

Aquí te hablo más acerca de los code smells.

Por ejemplo, mira este código:

public class Order
{
    public string Email { get; set; }
    public decimal Amount { get; set; }
}

A simple vista, no tiene nada de malo, es una clase común y silvestre.

Pero a un ojo entrenado, como asumo que tú quieres ser, sí contiene potenciales problemas.

Te repito, a simple vista parece correcto, pero hay un problema:

Email y Amount no son simples primitivos en el dominio. Son conceptos con reglas:

• Un email debe tener un formato válido.
• Un monto no puede ser negativo.
• Etc...

Si dejamos esas validaciones dispersas en el código, terminaremos con duplicación, inconsistencias y lógica regada por todas partes.
Ahí es donde entran los Value Objects.

Qué es un Value Object

Un Value Object es un tipo que:

• Representa un concepto del dominio (por ejemplo, EmailAddress, Money, PhoneNumber).
• No tiene identidad propia (dos Money(10, "USD") son iguales si tienen los mismos valores).
• Encapsula reglas y comportamientos que pertenecen al concepto.

Este concepto de Value Object nace en Domain Driven Design, es decir, allí se formaliza, pero no pertenece sólo a DDD, al ser una idea general de buen diseño orientado a objetos se puede aplicar a cualquier arquitectura.

Ejemplo real en C#

Reescribamos el ejemplo anterior usando Value Objects:

public record Email
{
    public string Value { get; }

    public Email(string value)
    {
        if (string.IsNullOrWhiteSpace(value))
            throw new ArgumentException("Email cannot be empty.");

        if (!value.Contains("@"))
            throw new ArgumentException("Invalid email format.");

        // Puedes añadir todas las validaciones que necesites...

        Value = value;
    }

    public override string ToString() => Value;
}

public record Money
{
    public decimal Amount { get; }
    public string Currency { get; }

    public Money(decimal amount, string currency)
    {
        if (amount < 0)
            throw new ArgumentException("Amount cannot be negative.");
        if (string.IsNullOrWhiteSpace(currency))
            throw new ArgumentException("Currency is required.");

        Amount = amount;
        Currency = currency;
    }

    public override string ToString() => $"{Amount} {Currency}";
}

Y la entidad ahora luce mucho más limpia:

public class Order
{
    public Email CustomerEmail { get; private set; }
    public Money Total { get; private set; }

    public Order(Email email, Money total)
    {
        CustomerEmail = email;
        Total = total;
    }
}

Ahora, Order se centra en su propósito (gestionar órdenes) y no en validaciones de bajo nivel.
El dominio se vuelve expresivo, seguro y autoexplicativo.

En conclusión dev...

Los Value Objects no son exclusivos de DDD o Clean Architecture, son una buena práctica universal.
Usarlos te ayudará a:

• Eliminar el code smell “Primitive Obsession”.
• Centralizar reglas del dominio.
• Hacer tu código más claro y menos propenso a errores.

Así que ya sabes, estimado dev, cada vez que un tipo primitivo tenga significado propio en el dominio, conviértelo en un Value Object.

¿Te encantó esta entrada, no? Haz tu buena obra del día y comparte este artículo entonces en tus redes sociales y por supuesto a todo tu equipo de ingeniería 😉🐿️

Créditos de imagen de portada: Basado en Foto de Amy Baugess en Unsplash