Cuando las aplicaciones crecen mucho, la arquitectura simple de:

1Controller → Service → Repository

puede quedarse corta.

Para proyectos grandes se utilizan arquitecturas más avanzadas como:

• Arquitectura Hexagonal
• Clean Architecture
• Domain Driven Design (DDD)

Estas arquitecturas permiten:

• separar responsabilidades
• mejorar mantenimiento
• facilitar testing
• escalar aplicaciones grandes

---

16.1 Problema de la arquitectura tradicional

En muchos proyectos el código termina así:

1Controller
2Service
3Repository
4Entity

El problema es que:

• la lógica de negocio se mezcla con la infraestructura
• la base de datos afecta al diseño
• cambiar tecnología es difícil

Ejemplo:

1@Service
2public class OrderService {
3
4    private final OrderRepository repository;
5
6}

Aquí el dominio depende directamente del repositorio.

---

16.2 Principio clave: separar dominio

Las arquitecturas modernas separan:

1Dominio
2Infraestructura

---

Dominio

Contiene:

• reglas de negocio
• modelos
• lógica principal

---

Infraestructura

Contiene:

• base de datos
• APIs externas
• frameworks

---

16.3 Arquitectura Hexagonal

También llamada:

1Ports and Adapters

El sistema se organiza así:

1Controller
2           ↓
3        Application
4           ↓
5         Domain
6           ↑
7        Repository

El dominio no depende de la infraestructura.

---

16.4 Estructura de carpetas

Ejemplo típico:

1src/main/java/com/example/app
2
3domain
4   model
5   service
6   repository
7
8application
9   usecase
10
11infrastructure
12   controller
13   persistence
14   config

---

16.5 Dominio

Aquí viven las reglas de negocio.

---

Ejemplo entidad de dominio

1public class User {
2
3    private Long id;
4
5    private String email;
6
7    public boolean isValidEmail() {
8        return email.contains("@");
9    }
10
11}

El dominio no conoce Spring ni JPA.

---

16.6 Repositorio como interfaz

En arquitectura hexagonal los repositorios son interfaces.

---

Ejemplo

1public interface UserRepository {
2
3    User save(User user);
4
5    Optional<User> findById(Long id);
6
7}

Esto pertenece al dominio.

---

16.7 Implementación del repositorio

La implementación está en infraestructura.

---

Ejemplo

1@Repository
2public class JpaUserRepository implements UserRepository {
3
4    private final SpringDataUserRepository repository;
5
6}

Aquí sí usamos JPA.

---

16.8 Casos de uso (Use Cases)

La capa application contiene los casos de uso.

Ejemplo:

1public class CreateUserUseCase {
2
3    private final UserRepository repository;
4
5    public User execute(CreateUserCommand command) {
6
7        User user = new User();
8        user.setEmail(command.email());
9
10        return repository.save(user);
11
12    }
13
14}

---

16.9 Controller como adaptador

El controller solo conecta HTTP con el caso de uso.

---

Ejemplo

1@RestController
2@RequestMapping("/users")
3public class UserController {
4
5    private final CreateUserUseCase useCase;
6
7    @PostMapping
8    public UserDTO createUser(@RequestBody CreateUserDTO dto) {
9
10        return useCase.execute(dto);
11
12    }
13
14}

---

16.10 Flujo completo

El flujo sería:

1HTTP Request
2     ↓
3Controller
4     ↓
5Use Case
6     ↓
7Domain
8     ↓
9Repository interface
10     ↓
11Repository implementation
12     ↓
13Database

---

16.11 Ventajas de arquitectura hexagonal

ventaja	explicación
dominio independiente	no depende de frameworks
testing fácil	dominio sin base de datos
flexibilidad	cambiar infraestructura
código limpio	responsabilidades claras

---

16.12 Qué es Domain Driven Design (DDD)

DDD significa:

1Domain Driven Design

Es una forma de diseñar software basada en el dominio del negocio.

---

Conceptos clave de DDD

concepto	significado
Entity	objeto con identidad
Value Object	objeto sin identidad
Repository	acceso al dominio
Aggregate	grupo de entidades
Use Case	acción del sistema

---

16.13 Ejemplo Value Object

1public class Email {
2
3    private final String value;
4
5    public Email(String value) {
6
7        if(!value.contains("@")) {
8            throw new IllegalArgumentException("Email inválido");
9        }
10
11        this.value = value;
12
13    }
14
15}

Esto garantiza que el email siempre sea válido.

---

16.14 Cuándo usar arquitectura avanzada

No todos los proyectos necesitan esto.

---

Usar arquitectura simple cuando

• proyecto pequeño
• API sencilla
• prototipo

---

Usar arquitectura hexagonal cuando

• proyecto grande
• dominio complejo
• microservicios
• equipos grandes

---

16.15 Ejemplo de proyecto profesional

1com.example.app
2
3domain
4   model
5   repository
6
7application
8   usecase
9
10infrastructure
11   controller
12   persistence
13   config

Esta estructura es muy común en empresas.