Arquitectura avanzada

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

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.

2. Principio clave: separar dominio #

Las arquitecturas modernas separan:

1Dominio
2Infraestructura

3. Dominio #

Contiene:

• reglas de negocio
• modelos
• lógica principal

4. Infraestructura #

Contiene:

• base de datos
• APIs externas
• frameworks

5. 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.

6. 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

7. Dominio #

Aquí viven las reglas de negocio.

8. 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.

9. Repositorio como interfaz #

En arquitectura hexagonal los repositorios son interfaces.

10. Ejemplo #

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

Esto pertenece al dominio.

11. Implementación del repositorio #

La implementación está en infraestructura.

12. Ejemplo #

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

Aquí sí usamos JPA.

13. 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}

14. Controller como adaptador #

El controller solo conecta HTTP con el caso de uso.

15. 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. Flujo completo #

El flujo sería:

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

17. Ventajas de arquitectura hexagonal #

18. Qué es Domain Driven Design (DDD) #

DDD significa:

1Domain Driven Design

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

19. Conceptos clave de DDD #

20. 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.

21. Cuándo usar arquitectura avanzada #

No todos los proyectos necesitan esto.

22. Usar arquitectura simple cuando #

• proyecto pequeño
• API sencilla
• prototipo

23. Usar arquitectura hexagonal cuando #

• proyecto grande
• dominio complejo
• microservicios
• equipos grandes

24. 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.