El Principio Fundamental: El Dominio No Conoce la Infraestructura
En Arquitectura Hexagonal (creada por Alistair Cockburn), el código de negocio (dominio) vive en el centro del sistema y NO depende de frameworks, bases de datos, HTTP ni mensajería. La regla de dependencia es estricta: las capas externas (infraestructura) dependen del centro (dominio), NUNCA al revés.
En una línea public interface PedidoRepository { void guardar(Pedido pedido); Optional<Pedido> buscarPorId(UUID id); } // Interfaz PURA del dominio, sin @Repository ni Spring
package com.acme.taskflow.tareas.dominio;
// Sin imports de Spring, JPA ni Jackson
public final class Tarea {
private final TareaId id;
private final ProyectoId proyecto;
private String titulo;
private EstadoTarea estado;
private Responsable responsable;
public static Tarea nueva(TareaId id, ProyectoId proyecto, String titulo) {
return new Tarea(id, proyecto, titulo, EstadoTarea.PENDIENTE, null);
}
public void asignarA(Responsable nuevo) {
if (estado == EstadoTarea.COMPLETADA) {
throw new TareaCerradaException(id);
}
this.responsable = Objects.requireNonNull(nuevo);
}
public void completar() {
if (responsable == null) throw new TareaSinResponsableException(id);
this.estado = EstadoTarea.COMPLETADA;
}
// constructor completo, getters de solo lectura...
}
public record TareaId(UUID valor) {
public static TareaId nuevo() { return new TareaId(UUID.randomUUID()); }
}
Cómo funciona por dentro
La idea central de la arquitectura hexagonal (Alistair Cockburn) es que la aplicación tiene un interior, el dominio y los casos de uso, y un exterior, todo lo que es tecnología: HTTP, bases de datos, colas, proveedores externos, la línea de comandos. El interior no depende del exterior; es el exterior el que se adapta al interior.
En código, eso significa que las clases del dominio no importan nada de org.springframework, jakarta.persistence, com.fasterxml.jackson ni clientes HTTP. Son Java puro: entidades con comportamiento, objetos de valor, excepciones y servicios de dominio.
El beneficio es doble. El dominio se prueba con tests unitarios rápidos, sin contexto de Spring ni contenedores. Y las decisiones tecnológicas se pueden cambiar o posponer, porque están confinadas en los bordes. El coste es más código de mapeo y más estructura, que solo compensa cuando hay lógica de negocio real que proteger.
@Service, @Autowired) o de JPA (@Entity, @Column) en las clases del dominio, acoplándolas a la infraestructura.
Se conecta con SOLIDInversión de Dependencias (DIP)Testabilidad