¿Estás usando esta arquitectura? O ¿vas a seguir haciendo lo que te da la gana?

Hola amante del código limpio y del orden,

Como sé que te gustan las cosas bien estructuradas y que quieres hacer bien las cosas, te traigo esta pequeña guía para que empieces a aplicar una de las arquitecturas más famosas:

CLEAN ARCHITECTURE

(Seguro que te suena… te la habrán preguntado en muchas entrevistas junto con la Arquitectura hexagonal)

Pero antes de pasar a los ejemplos…. Déjame explicarte.

---

¿Qué es esto realmente?

Pues a ver, esto de “Clean Architecture”, no es un nuevo framework, ni una librería, ni una moda de LinkedIn.

Es una forma de estructurar el código, y gracias a esta forma conseguimos que nuestro proyecto sea:

✅ Fácil de mantener

✅ Fácil de testear

✅ Fácil de entender

Y todo esto lo consigue con una idea muy sencilla:

👉 Poner lo importante en el centro… y lo accesorio fuera.

Te acuerdas de la arquitectura de la cebolla…. Pues esto es “parecido”, al final todas estas arquitecturas se centran en darle la importancia que necesita a la capa de negocio, que es lo que va a cambiar poco, y fuera las cosas con son más susceptibles de cambios.

Entonces….

¿Qué es lo importante aquí?

Tu dominio.

Tus reglas de negocio.

Y tu café.

Vamos, lo que hace que tu aplicación sea tuya y no igual a todas las demás.

Todo lo que no sea eso —frameworks, bases de datos, controladores, APIs externas— es solo una herramienta que puede cambiar.

Imagina una diana:

🎯 En el centro: Entities → son tus reglas de negocio puras.

🎯 Luego: Use Cases → los casos de uso que orquestan qué se hace y en qué orden.

🎯 Más afuera: Interface Adapters → aquí están los controladores, DTOs, mappers…

🎯 En el borde: Frameworks & Drivers → bases de datos, librerías, el propio Spring, etc.

Y lo que te tienes que grabar a fuego en la cabeza:

Nada hacia dentro puede depender de lo que está fuera.

Es decir, a tu negocio, le da igual si estás usando Spring Boot o lo que sea, le da igual que base de datos estás usando.

¿Pero Goico, y esto para qué me va a servir?

Pues imagina que mañana cambias de base de datos. (Sé que es poco probable… pero lo he visto)

O decides cambiar de librería de envío de emails. (Esto sí lo he visto mucho, que tengas que cambiar una dependencia que uses)

O tu app pasa de REST a GraphQL.

👉 Si montaste tu arquitectura con Clean Architecture, el corazón de tu aplicación no se entera de nada.

Sigue funcionando igual.

Y esto es ******, digo muy bueno.

Vale… ya lo entiendo… pero… ¿Y mi ejemplo?

---

Un ejemplo MUY simple con Clean Architecture

Vamos a simular un caso de uso básico: crear un pedido.

🔹 Dominio (Entities):

public class Pedido {
    private String producto;
    private int cantidad;

    public Pedido(String producto, int cantidad) {
        if (cantidad <= 0) {
            throw new IllegalArgumentException("Cantidad inválida");
        }
        this.producto = producto;
        this.cantidad = cantidad;
    }

    // Getters y lógica relacionada
}

---

🔹 Caso de uso (Application/Use Case):

public class CrearPedidoUseCase {
    private final PedidoRepository repository;

    public CrearPedidoUseCase(PedidoRepository repository) {
        this.repository = repository;
    }

    public void ejecutar(String producto, int cantidad) {
        Pedido pedido = new Pedido(producto, cantidad);
        repository.guardar(pedido);
    }
}

---

🔹 Interfaz (Interface Adapter):

public interface PedidoRepository {
    void guardar(Pedido pedido);
}

---

🔹 Infraestructura (Implementación real):

public class PedidoRepositoryImpl implements PedidoRepository {
    public void guardar(Pedido pedido) {
        // Lógica para guardar en base de datos
        System.out.println("Guardando pedido de: " + pedido.getProducto());
    }
}

---

🔹 Controlador (entrada al sistema):

public class PedidoController {
    private final CrearPedidoUseCase useCase;

    public PedidoController() {
        PedidoRepository repository = new PedidoRepositoryImpl();
        this.useCase = new CrearPedidoUseCase(repository);
    }

    public void crearPedido(String producto, int cantidad) {
        useCase.ejecutar(producto, cantidad);
    }
}

---

Como ves, cada clase cumple un rol claro, y lo más importante:

El dominio no depende de nada.

Puedes cambiar la base de datos, la forma de exponer la API… y lo que tienes en el centro ni se entera.

Venga, pues hoy mismo me voy a cambiar todo a esta arquitectura.

Esperaaaa! Sigue leyendo anda.

¿Entonces Clean Architecture es perfecta?

No. Nada lo es.

Tiene su curva de aprendizaje.

Y no siempre necesitas montar toda esta parafernalia si estás haciendo una API pequeñita para una hackathon.

Pero si trabajas en un proyecto serio, con muchos módulos, reglas de negocio complejas y equipos grandes…

Clean Architecture es tu mejor amiga.

Y nada, espero que te haya gustado y ya me dices si la estás empezando a usar, o si te vas a quedar con tu arquitectura de momento.

Nos leemos en una semana.