DEV Community: Federico Herrera

Llegó MFA con Spring Security 7

Federico Herrera — Tue, 23 Dec 2025 14:00:00 +0000

Desde su salida, Spring Security no ofreció soporte nativo para Multi-Factor Authentication (MFA). Implementar un segundo factor como un código temporal, de esos que te mandan un codigo por SMS o Whatsapp, una app autenticadora o un token, implicaba crear filtros personalizados, AuthenticationProviders propios y manejar estados intermedios de autenticación a mano. Cada implementación terminaba siendo distinta.

Finalmente, Spring Security 7 lo hizo. El framework introduce soporte oficial y declarativo para MFA, integrándolo directamente en su modelo de autenticación y autorización. Ahora, cada factor autenticado se representa como una autoridad, permitiendo definir reglas de acceso que exigen múltiples factores sin necesidad de lógica personalizada ni flujos improvisados.

Ahora vamos a ver qué resuelve este nuevo soporte y cómo implementar MFA de manera simple y consistente.

Naturalmente, la fuente final de la verdad es la documentación oficial, que se mantiene actualizada por los desarrolladores y la comunidad.

¿Qué es MFA?

Hay un montón de recursos online para responder esta pregunta así que a efectos de este post lo vamos a simplificar, si quieres profundizar, consúltale a Google o a tu IA de confianza.

Básicamente, MFA (Multi-Factor Authentication) es un mecanismo de autenticación que requiere de 2 o más formas de probar que eres quien dices ser para acceder a un recurso o sección de una aplicación. La forma más común, y que posiblemente ya conozcas, de esta técnica, es cuando al loguearte a una aplicación usando tu usuario y contraseña o tu cuenta de mail, necesites, además, validar un código que el sistema te envía a tu celular mediante SMS o Whatsapp o que hagas click en un enlace que te envien por cualquier medio. Otras formas involucran biometría, como tu huella dactilar o escáner facial, en la mayoria de dispositivos moviles, o una llave física, por lo general la empresa para la que trabajes puede llegarte a brindar uno de estos dispositivos.

¿Cómo lo implemento en mi proyecto?

Sin mas preámbulo, vamos a ver cómo implementar estos mecanismos en tu aplicación BE Spring.

Para no ser una duplicado de la guía de la documentación voy a hacer leverage de uno de los estándares más usados para autenticación, JWT.
Y es que por diseño Spring Security hace uso de sesiones, véase Session Management, pero la mayoría de las veces mantenemos RESTful APIs y necesitamos mantenerlas stateless para asegurar consistencia.

Un estándar muy utilizado es hacer uso de tokens, donde especificamos las capacidades del usuario una vez se autentica y este lo utiliza como tarjeta de entrada para acceder a los recursos del sistema.

Planteamos los siguientes requerimientos:

POST /login

En caso de que sean las credenciales válidas, construimos el token, caso contrario retornamos.

GET /user/settings

Solo usuarios autenticados pueden acceder al recurso.
Autencicación por token soportada.
En caso de que el cliente provea un token y sea válido, puede acceder al recurso. Caso contrario retornamos.

Muy bien, para esto podemos hacer algo bastante simple en Spring, primeramente necesitamos algo que nos permita construir el token y decodificarlo/validarlo.

Para esta demo hago uso de las implementaciones estándar de Spring con certificados estáticos, algo que no es la mejor de las prácticas ni mucho menos recomendable para producción, pero didácticamente nos va a ayudar a reducir el , no voy a entrar en detalle de las implementaciones, pero puedes revisar el código del proyecto si te da curiosidad.

Entonces configuramos 2 beanes para llevar esto acabo, un NimbusJwtEncoder y un NimbusJwtDecoder, implementaciones estándar de Spring.

Además, necesitamos un usuario para pruebas, por lo que vamos a crear un service que tenga un usuario de pruebas en memoria.

  @Bean
  UserDetailsService userDetailsService(PasswordEncoder passwordEncoder) {
    List<UserDetails> users =
        List.of(
            new User(
                "user",
                passwordEncoder.encode("password"),
                List.of(new SimpleGrantedAuthority("ROLE_USER"))));
    return new InMemoryUserDetailsManager(users);
  }

Debemos decirle a Spring que un usuario va a poder autenticarse usando información que tenemos en el sistema, en producción seria una BBDD, para este caso in-memory. Esto lo conseguimos simplemente definiendo un AuthenticationProvider que haga uso de algo así: Spring nos entrega DaoAuthenticationProvider para esto.

  @Bean
  AuthenticationManager authenticationManager(
      UserDetailsService userDetailsService, PasswordEncoder passwordEncoder) {
    DaoAuthenticationProvider authenticationProvider =
        new DaoAuthenticationProvider(userDetailsService);
    authenticationProvider.setPasswordEncoder(passwordEncoder);

    return new ProviderManager(authenticationProvider);
  }

Vemos que éste depende de un PasswordEncoder, además del UserDetailsService que definimos antes, de nuevo, todo está escrito.

  @Bean
  PasswordEncoder passwordEncoder() {
    return new BCryptPasswordEncoder();
  }

Este es todo nuestro setup, ahora solo debemos habilitar a cliente a hacer uso del servicio, un controller como este es suficiente:

@Slf4j
@RestController
@RequiredArgsConstructor
public class AuthController {
  private final AuthenticationManager authenticationManager;
  private final JwtEncoder jwtEncoder;

  @PostMapping(value = "/login", consumes = MediaType.APPLICATION_FORM_URLENCODED_VALUE)
  @ResponseStatus(HttpStatus.NO_CONTENT)
  ResponseEntity<Void> login(@RequestParam String username, @RequestParam String password) {
    var authRequest = new UsernamePasswordAuthenticationToken(username, password);
    log.info("Login: {}", authRequest);
    var auth = authenticationManager.authenticate(authRequest);
    String token =
        jwtEncoder
            .encode(
                JwtEncoderParameters.from(
                    JwsHeader.with(SignatureAlgorithm.RS256).build(),
                    JwtClaimsSet.builder()
                        .subject(auth.getName())
                        .claim(
                            SCOPE,
                            auth.getAuthorities().stream()
                                .map(GrantedAuthority::getAuthority)
                                .toList())
                        .expiresAt(Instant.now().plusSeconds(1000))
                        .build()))
            .getTokenValue();
    return ResponseEntity.noContent().header(AUTHORIZATION, "Bearer %s".formatted(token)).build();
  }
}

Una capa de servicio podría facilitar la segmentación pero a efectos de esta demo podemos tenerlo todo en el controlador.

Vamos por partes aquí, primero nos traemos el AuthenticationManager, como tenemos el método de autenticación por usuario y contraseña, creamos una instancia de UsernamePasswordAuthenticationToken que luego podemos pasar al auth provider, éste se va a encargar de decirnos si es válido.
Si pasa es porque las credenciales son correctas, por lo que procedemos a construir el token especificando el algoritmo de la firma, el subject que es el mismo username del usuario y agregamos las claims authorities del usuario, que nos permite despues saber cosas como el rol y cómo se autenticó. Ésta es la forma en la que Spring Security sabe a qué cosas puede acceder el usuario. Docs Authorities en Spring

Con ésto en su lugar, solo nos queda decirle a Spring como descomponer un token JWT y obtener sus authorities a partir de el, otro escenario tan común que ya lo tenemos con mínima configuración.

@Configuration
public class JwtAuthConfig {
  @Bean
  JwtAuthenticationConverter jwtAuthenticationConverter(
      JwtGrantedAuthoritiesConverter jwtGrantedAuthoritiesConverter) {
    val jwtAuthenticationConverter = new JwtAuthenticationConverter();
    jwtAuthenticationConverter.setJwtGrantedAuthoritiesConverter(jwtGrantedAuthoritiesConverter);
    return jwtAuthenticationConverter;
  }

  @Bean
  JwtGrantedAuthoritiesConverter jwtGrantedAuthoritiesConverter() {
    val jwtGrantedAuthoritiesConverter = new JwtGrantedAuthoritiesConverter();
    jwtGrantedAuthoritiesConverter.setAuthorityPrefix("");
    return jwtGrantedAuthoritiesConverter;
  }
}

Bastante autodeclarativo, pero solo le digo que necesito un conversor de JWT a Authentication y que no le ponga ningún prefijo a las Authorities que cree a partir del token.

Con esto tenemos casi todo lo que necesitamos, solo nos queda decirle a Spring que éste endpoint es público.

  @Bean
  SecurityFilterChain securityFilterChain(
      HttpSecurity http, JwtAuthenticationConverter jwtAuthenticationConverter) {
    http.csrf(AbstractHttpConfigurer::disable)
        .sessionManagement(sm -> sm.sessionCreationPolicy(SessionCreationPolicy.STATELESS))
        .authorizeHttpRequests(
            authorize ->
                authorize
                    .requestMatchers("/login")
                    .permitAll()
                    .anyRequest()
                    .authenticated())
        .oauth2ResourceServer(
            oauth -> oauth.jwt(jwt -> jwt.jwtAuthenticationConverter(jwtAuthenticationConverter)));
    return http.build();
  }

Definimos que la SecurityFilterChain desabilite el CSRF y que usaremos sesiones sin estado. El /login estará abierto y cualquier otro request necesita estar autenticado. Al final, le indicamos que el server Oauth2 use el JwtAuthenticationConverter que definimos anteriormente.

Por supuesto necesitamos testearlo:

  @Test
  void mfaTest() {
    MockHttpServletResponse response =
        mockMvcTester
            .post()
            .contentType(MediaType.APPLICATION_FORM_URLENCODED)
            .uri("/login")
            .param("username", "user")
            .param("password", "password")
            .exchange()
            .assertThat()
            .containsHeader(AUTHORIZATION)
            .actual()
            .getResponse();

    var token = requireNonNull(response.getHeader(AUTHORIZATION));
    var decoded = jwtDecoder.decode(token.replace("Bearer ", ""));
    assertThat(decoded.getSubject()).isEqualTo("user");
    assertThat(decoded.getClaimAsStringList(SCOPE)).contains("ROLE_USER");
  }

Aquí me traigo el NimbusJwtDecoder que utiliza la aplicación para decodificar y valido que el token que me genera el endpoint es válido. Las credenciales son las que definí en mi UserDetailsService en memoria.

Con esto en su lugar, puedo habilitar el servicio de /user/settings:

@RestController
@RequestMapping("/user")
public class UserController {

  @GetMapping("/settings")
  ResponseEntity<Map<String, String>> getSettings() {
    return ResponseEntity.ok(Map.of("found", "config"));
  }
}

Hermosa configuración.

Y securizarlo:

  @Bean
  SecurityFilterChain securityFilterChain(
      HttpSecurity http, JwtAuthenticationConverter jwtAuthenticationConverter) {
    http
    // etc etc
        .authorizeHttpRequests(
            authorize ->
                authorize
                    .requestMatchers("/login")
                    .permitAll()
                    .requestMatchers("/user/settings")
                    .hasRole("USER")
                    .anyRequest()
                    .authenticated())
    // etc etc
    return http.build();
  }

El JwtAuthenticationConverter que definí antes va a leer el token y asígnar el Authority con el rol correspondiente.

Agregando MFA

Resulta que ahora queremos que, además de que el usuario esté autenticado, valide un código que recibirá por mail o SMS cuando quiera acceder a las settings.
Ahora el requerimiento de seguridad para acceder a las settings es así:

En caso de que alguna condición falle, siempre REJECT.

Para esto vamos a crear un endpoint donde el cliente puede solicitar un OTT, podríamos dispararlo directamente del endpoint cuando falle, pero sería un acople innecesario.

Veamos entonces la implementación:

@RestController
@RequestMapping("/ott")
@RequiredArgsConstructor
public class OttController {
  private final JwtEncoder jwtEncoder;
  private final Map<String, OneTimeToken> tokens = new HashMap<>();

  @PostMapping
  @ResponseStatus(HttpStatus.NO_CONTENT)
  void getOttCode() {
    var auth = requireNonNull(SecurityContextHolder.getContext().getAuthentication());
    var ott =
        new DefaultOneTimeToken(
            UUID.randomUUID().toString(), auth.getName(), Instant.now().plusSeconds(1000));

    tokens.put(auth.getName(), ott);
  }
}

A efectos de una demo, vamos a guardar los tokens en un mapa, en producción, este storage debería ser un cache distribuido o datastore con TTL.

Creamos un método publico para validarlo en el test, que lo extendemos así:

    mockMvcTester
        .post()
        .contentType(MediaType.APPLICATION_JSON)
        .uri("/ott")
        .header(AUTHORIZATION, token)
        .exchange()
        .assertThat()
        .hasStatus(HttpStatus.NO_CONTENT);

    assertThat(ottController.getToken("user")).isNotNull();

Muy sencillito.

El soporte de MFA existe, pero no se activa automáticamente, así que lo habilitamos agregando la anotación @EnableMultiFactorAuthentication(authorities = {}) a nuestra clase de configuracion de Spring Security, authorities vacías ya que especificar aquí los métodos de autenticación los habilitaria globalmente.

Para obtener el token OTT dijimos que el usuario debería estar autenticado de antemano, como ahora tenemos multiples factores, tenemos que decirle a Spring Security cómo debería estar autenticado para obtenerlo, así que nuestro filter chain quedaría así:

  @Bean
  SecurityFilterChain securityFilterChain(
      HttpSecurity http, JwtAuthenticationConverter jwtAuthenticationConverter) {
    val bearerFactor =
        AuthorizationManagerFactories.multiFactor()
            .requireFactors(FactorGrantedAuthority.BEARER_AUTHORITY)
            .build();
    http
    // etc etc
        .authorizeHttpRequests(
            authorize ->
                authorize
                    .requestMatchers("/ott")
                    .access(bearerFactor.hasRole("USER"))
                    .anyRequest()
                    .authenticated());
    // etc etc
    return http.build();
  }

¿Qué está pasando aquí?
Ahora necesitamos un manager de autorización que valide que el usuario se autenticó con Bearer Token, JWT.
Y le decimos que para invocar /ott necesita éste método de autenticación además de tener el rol USER.
Con el setup que tenemos, esto es todo lo que necesitamos, al utilizar un JwtAuthenticationConverter éste agrega por default FactorGrantedAuthority#BEARER_AUTHORITY a la autenticación del contexto.

Entonces ahora solo necesitamos validar el token OTT, en producción éste lo mandaríamos por mail o SMS, aquí, vive en memoría y lo obtengo con un método público en el controlador.

  @PostMapping("/login")
  @ResponseStatus(HttpStatus.NO_CONTENT)
  ResponseEntity<Void> validateOtt(@RequestParam String ott) {
    var auth = requireNonNull(SecurityContextHolder.getContext().getAuthentication());
    var ottToken = tokens.get(auth.getName());
    if (isNull(ottToken) || !ottToken.getTokenValue().equals(ott)) {
      throw new IllegalArgumentException();
    }
    List<String> authorities =
        Stream.of(
                List.of(FactorGrantedAuthority.fromAuthority(FactorGrantedAuthority.OTT_AUTHORITY)),
                auth.getAuthorities())
            .flatMap(Collection::stream)
            .map(GrantedAuthority::getAuthority)
            .toList();
    String token =
        jwtEncoder
            .encode(
                JwtEncoderParameters.from(
                    JwsHeader.with(SignatureAlgorithm.RS256).build(),
                    JwtClaimsSet.builder()
                        .subject(auth.getName())
                        .claim(SCOPE, authorities)
                        .expiresAt(Instant.now().plusSeconds(1000))
                        .build()))
            .getTokenValue();
    return ResponseEntity.noContent().header(AUTHORIZATION, "Bearer %s".formatted(token)).build();
  }

  public OneTimeToken getToken(String username) {
    return tokens.get(username);
  }

El usuario debe pegarle al endpoint con el código que "le llegó por mail" y, si existe, le agregamos a los authorities el FactorGrantedAuthority#OTT_AUTHORITY indicándo que se autenticó correctamente con éste metodo y creamos un nuevo tóken con toda la información que ya tenía, que luego puede usar para buscar sus settings.

Lo último sería completar nuestro test:

    response =
        mockMvcTester
            .post()
            .uri("/ott/login")
            .queryParam("ott", ott)
            .header(AUTHORIZATION, token)
            .exchange()
            .assertThat()
            .debug()
            .hasStatus(HttpStatus.NO_CONTENT)
            .containsHeader(AUTHORIZATION)
            .extracting(MvcTestResult::getResponse)
            .actual();

    var auth = response.getHeader(AUTHORIZATION);
    assertThat(auth).isNotNull();
    var updatedToken = auth.replace("Bearer ", "");
    assertThatNoException().isThrownBy(() -> jwtDecoder.decode(updatedToken));
    decoded = jwtDecoder.decode(updatedToken);
    assertThat(decoded.getSubject()).isEqualTo("user");
    assertThat(decoded.getClaimAsStringList(SCOPE)).contains("FACTOR_OTT", "FACTOR_BEARER");

Donde testeamos que, con el token que teniamos de la autenticación con contraseña podemos acceder a /ott/login y obtener el nuevo token con ambos factores de autenticación.

El soporte nativo de MFA en Spring Security 7 no introduce nuevos mecanismos de verificación por sí mismo, sino algo mucho más importante: un modelo consistente para representarlos y exigirlos.

En lugar de flujos especiales, estados intermedios o lógica dispersa en filtros y controladores, cada factor de autenticación pasa a formar parte explícita del Authentication del usuario, expresado como autoridades verificables. Esto permite que la autorización se base en hechos comprobables, qué factores fueron validados, y no en suposiciones implícitas o banderas temporales.

Este enfoque encaja naturalmente con arquitecturas stateless, JWT y APIs REST, y se alinea con cómo los sistemas de identidad modernos modelan la autenticación progresiva o step-up authentication. El resultado es un sistema más simple de razonar, más fácil de mantener y mucho menos propenso a errores sutiles de seguridad.

Spring Security 7 no hace que MFA sea “mágico”, pero finalmente lo hace predecible, declarativo y bien integrado en su ecosistema. Y eso, para quienes ya tuvieron que implementarlo a mano más de una vez, es un cambio enorme.

Como siempre, todo el código está disponible para que lo revises en el proyecto de github

Simplificando Inversion of Control y Dependency Injection

Federico Herrera — Wed, 10 Dec 2025 14:00:00 +0000

Inversión de Control (IoC) y Inyección de Dependencias (DI) son dos conceptos que aparecen en prácticamente cualquier entrevista de desarrollo web. Y aun así, muchos desarrolladores con años de experiencia no siempre pueden explicarlos con claridad. No porque no los entiendan, al contrario, sino porque están tan asimilados en el día a día que dejan de ser visibles.

Un pequeño repaso nunca viene mal.

Inversion of Control

IoC es un principio fundamental en el que se apoyan todos los frameworks modernos. La idea central es simple:

Dejar que el Framework lo haga por vos.

Cuando usamos un framework backend como Spring, este toma control de una enorme cantidad de responsabilidades que, sin él, tendrías que escribir a mano:

manejar el ciclo de vida del servidor,
gestionar hilos y concurrencia,
rutear cada request,
leer y escribir sobre streams I/O,
serializar y deserializar datos,
manejar excepciones,
y proveer herramientas de testing sobre todo eso.

Eso es IoC: el control deja de estar en tu código y pasa al framework.

Django (Python)
Express.js (Node)
Gin / Gorilla (Go)

Dependency Injection

A diferencia de IoC, DI es un patrón de diseño. Podés usar un framework sin DI, o usar DI sin un framework. Su objetivo es resolver un problema puntual: la provisión de dependencias.

Cuando una clase necesita algo que está implementado en otra, aparece una dependencia. Por ejemplo:

public class EmailSender {
    private final EmailWriter emailWriter;

    public EmailSender(EmailWriter emailWriter) {
        this.emailWriter = emailWriter;
    }

    public void sendEmail(EmailContent emailContent) {
        var email = emailWriter.writeEmail(emailContent);
        // etc etc
    }
}

En éste ejemplo podemos ver que EmailSender depende de EmailWriter, usarlo arrojaría NullPointerException en caso de que no se proporcione.

En éste caso si no tuvieramos DI tendríamos 2 soluciones.

Crear la dependencia desde afuera

public class SomeService {
     public void notifySomething(Destiny destiny) {
         var emailWriter = new EmailSender(new EmailWriter());
         EmailContent emailContent = buildEmailContent(destiny);
         emailSender.sendEmail(emailContent);
     }
}

Crear la dependencia adentro del método

public class EmailSender {

    public void sendEmail(EmailContent emailContent) {
        var emailWriter = new EmailWriter();
        var email = emailWriter.writeEmail(emailContent);
        // etc etc
    }
}

Ambos enfoques tienen problemas puntuales:

Acople innecesario
Dificultad para testear
Imposibilidad de mockear dependencias
La responsabilidad de crear objetos termina “moviéndose de lugar”

DI resuelve esto delegando la gestión de dependencias al framework.

Demo

Supongamos un API donde los usuarios suben videos. Debemos:

Encriptar
Publicar
Persistir metadata

Además:

Soportamos dos tipos de video: MP4 y FLV
En desarrollo queremos guardar localmente, pero en producción debemos usar un cloud provider
Queremos poder cambiar de proveedor sin tocar el servicio

Intentaremos evitar hacer:

if (isProd()) {
  // usar cloud
} else {
  // guardar en local
}

Tenemos entonces:

Aplicando IoC y DI

Para el publisher podemos hacer uso de una interfaz común y profiles, permitiendonos tener 2 implementaciones distintas y solo le indicamos al framework caundo usar cada una y que se encargue del resto.

La interfaz común:

public interface VideoPublisher {
    URI publishContent(VideoPostRequest videoPostRequest);
}

Implementación local:

@Component
@Profile("local")
public class LocalVideoPublisher implements VideoPublisher {
    private static final Logger log = LoggerFactory.getLogger(LocalVideoPublisher.class);

    @Override
    public URI publishContent(VideoPostRequest videoPostRequest) {
        log.info("We save the video locally");
        return URI.create("file:///local/test/video123");
    }
}

Productiva:

@Component
@Profile("prod")
public class CloudVideoPublisher implements VideoPublisher {
    private static final Logger log = LoggerFactory.getLogger(CloudVideoPublisher.class);

    @Override
    public URI publishContent(VideoPostRequest videoPostRequest) {
        log.info("Posting to cloud provider!");
        return URI.create("https://mycloudprovider.com/uploads/video123");
    }
}

Y nuestro service puede simplemente hacer uso de la interfaz, sin involucrarse en detalles:

var link = videoPublisher.publishContent(...)

DI nos permite testearlo de forma tan simple como dandole un perfil contextual al test y validando que la URI es la esperada:

@SpringBootTest
@ActiveProfiles("local")
class LocalVideoServiceTest {
    @Autowired VideoService videoService;
    @Autowired VideoRepository videoRepository;

    @Test
    void shouldSaveLocally() {
        var input = new VideoRequest(VideoType.MP4, new byte[]{}, "My title", "My description", 1L);
        var result = videoService.postVideo(input);

        var actual = videoRepository.findById(result);

        assertThat(actual).get()
                .extracting(Video::link)
                .isEqualTo(URI.create("file:///local/test/video123"));
    }
}

Profile = prod

@SpringBootTest
@ActiveProfiles("prod")
class ProdVideoServiceTest {
    @Autowired VideoService videoService;
    @Autowired VideoRepository videoRepository;

    @Test
    void shouldSaveOnCloudProvider() {
        var input = new VideoRequest(VideoType.MP4, new byte[]{}, "Some other video", "Significant description", 2L);
        var result = videoService.postVideo(input);

        var actual = videoRepository.findById(result);

        assertThat(actual).get()
                .extracting(Video::link)
                .isEqualTo(URI.create("https://mycloudprovider.com/uploads/video123"));
    }
}

Spring: la Feature que Tardó 6 Años en Llegar (Y Cómo Cambia Todo)

Federico Herrera — Fri, 14 Nov 2025 14:00:00 +0000

Recientemente, en un proyecto en el que estoy trabajando, me encontré con un escenario interesante. Estuve un tiempo explorando posibles enfoques hasta que se me ocurrió uno que me pareció bastante elegante.

Simplificando: recibimos mensajes que, según una combinación de códigos, deben disparar distintas tareas.

Mi idea fue aplicar un diseño basado en una factory que devuelva una estrategia dependiendo de esa combinación. Gráficamente se vería así:

El service, usando esta petición, consulta a la factory por una estrategia para el caso. La factory, según la combinación de códigos, retorna una estrategia que el service puede ejecutar. El service nunca sabe que estrategia ejecuta — eso lo determina la factory.

Cada estrategia es granular, fácil de testear y Open/Closed: puedo agregar nuevas estrategias sin modificar las existentes, solo creo una nueva estrategia anotada con @Component.

Vamos al código

Tenemos una interfaz Strategy muy simple, solo nos dice que combinacion de códigos soporta y expone un método que ejecuta la lógica de negocio para el mensaje dado.

public interface Strategy {
    void consumeMessage(Message message);

    TypeEnum supportsType();

    SubTypeEnum supportsSubType();
}

Una implementación típica para la combinacion FOO|BAR, por ejemplo, se vería así:


@Component
public class FooBarStrategy implements Strategy {
    private static final Logger log = LoggerFactory.getLogger(FooBarStrategy.class);

    @Override
    public void consumeMessage(Message message) {
        log.info("Hi from FooBar");
    }

    @Override
    public TypeEnum supportsType() {
        return TypeEnum.FOO;
    }

    @Override
    public SubTypeEnum supportsSubType() {
        return SubTypeEnum.BAR;
    }
}

Los metodos supportsType y supportsSubType le dicen la factory para que combinación de códigos está pensado esta estrategia.

La factory por su lado se vería asi:

@Component
public class StrategiesFactory {
    private final Map<Pair<TypeEnum, SubTypeEnum>, Strategy> strategyMap;

    public StrategiesFactory(List<Strategy> strategies) {
        strategyMap = strategies.stream()
                .collect(
                        toMap(strategy -> Pair.of(strategy.supportsType(), strategy.supportsSubType()), Function.identity())
                );
    }

    public Strategy getStrategy(Message message) {
        var strategy = strategyMap.get(Pair.of(message.type(), message.subTypeEnum()));
        if (isNull(strategy)) {
            throw new IllegalArgumentException("Combination not supported");
        }
        return strategy;
    }
}

Spring permite inyectar listas de beans de un mismo tipo.
Así, puedo recibir todas las estrategias registradas sin declararlas una por una. Baeldung tiene un gran artículo al respecto! Pero si quieres que hable sobre esto a detalle en otro post, házmelo saber en los comentarios!

Para testear la implementación podemos usar un test parametrizado que valide que cada combinación de códigos retorna la estrategia esperada:

@SpringBootTest
class BeansdemoApplicationTests {
    @Autowired StrategiesFactory strategiesFactory;

    static Stream<Arguments> codeCombosAndExpectedStrategy() {
        return Stream.of(
                Arguments.of(TypeEnum.FOO, SubTypeEnum.BAR, FooBarStrategy.class),
                Arguments.of(TypeEnum.FOO, SubTypeEnum.BUZ, FooBuzStrategy.class),
                Arguments.of(TypeEnum.QUX, SubTypeEnum.BAR, QuxBarStrategy.class),
                Arguments.of(TypeEnum.QUX, SubTypeEnum.BUZ, QuxBuzStrategy.class)
        );
    }

    @ParameterizedTest
    @MethodSource("codeCombosAndExpectedStrategy")
    void shouldGetByCodesCombo(TypeEnum typeEnum, SubTypeEnum subTypeEnum, Class<Strategy> expectedStrategyClass) {
        var actualStrategy = strategiesFactory.getStrategy(new Message(typeEnum, subTypeEnum));

        assertThat(actualStrategy).isInstanceOf(expectedStrategyClass);
    }
}

El problema

Todo marchaba bien hasta que me doy con que ciertas combinaciones de códigos compartían la misma lógica: QUX|BAR y QUX|BUZ ejecutaban exactamente el mismo flujo:

@Component
public class QuxBarStrategy implements Strategy {
    private static final Logger log = LoggerFactory.getLogger(QuxBarStrategy.class);

    @Override
    public void consumeMessage(Message message) {
        log.info("Same impl here!");
    }

    @Override
    public TypeEnum supportsType() {
        return TypeEnum.QUX;
    }

    @Override
    public SubTypeEnum supportsSubType() {
        return SubTypeEnum.BAR;
    }
}

@Component
public class QuxBuzStrategy implements Strategy {
    private static final Logger log = LoggerFactory.getLogger(QuxBuzStrategy.class);

    @Override
    public void consumeMessage(Message message) {
        log.info("Same impl here!");
    }

    @Override
    public TypeEnum supportsType() {
        return TypeEnum.QUX;
    }

    @Override
    public SubTypeEnum supportsSubType() {
        return SubTypeEnum.BUZ;
    }
}

Podemos ver que los tipos que soportan son distintos, pero la implementacion de consumeMessage es idéntica: log.info("Same impl here!");

Como ambas estrategias tenían la misma implementación, esto violaba el principio DRY y escalaba mal a medida que aparecían más combinaciones similares.

¿Una solución?

La clave está en el método consumeMessage: es un Consumer<Message>.
Si lo pienso así, toda la clase podría reducirse a una estructura de datos que almacene ese consumer junto con los tipos que soporta:

public record DelegateStrategy(
        Consumer<Message> messageConsumer,
        TypeEnum typeSupported,
        SubTypeEnum subTypeEnum
) implements Strategy {
    @Override
    public void consumeMessage(Message message) {
        messageConsumer.accept(message);
    }

    @Override
    public TypeEnum supportsType() {
        return typeSupported();
    }

    @Override
    public SubTypeEnum supportsSubType() {
        return subTypeEnum();
    }
}

Con esta abstracción, puedo reutilizar la misma lógica (Consumer<Message>) para múltiples combinaciones de códigos, eliminando duplicación y manteniendo el diseño extensible.

Pre Spring Framework 7

En versiones anteriores no es posible registrar beans de forma dinámica, o por lo menos no para mi caso, BeanPostProcessor o similares son ejecutados demasiado tarde, cuando mi factory ya esta creada, estos se usan principalmente para hacer configuraciones posteriores.

En 2009 alguien abrió este issue pidiendo exactamente lo que necesito... que fue cerrado como invalid.

La única alternativa era registrar manualmente cada estrategia, repitiendo código y perdiendo flexibilidad.

Ahora, con Spring 7

Con Spring Framework 7 esto cambia. Ahora podemos registrar beans de forma programática usando la nueva API BeanRegistry, recordemos que (al momento de escribir este post) ésta version esta en construcción, por lo que no es estable.

    @Override
    public void register(BeanRegistry registry, Environment env) {
        if (Boolean.parseBoolean(env.getProperty("strategies.registrar"))) {
            Consumer<Message> commonImpl = _ ->  log.info("Same impl here!");
            registry.registerBean("quxBarStrategy", DelegateStrategy.class, spec -> spec.prototype()
                    .lazyInit()
                    .description("QuxBarStrategy bean")
                    .supplier(_ -> new DelegateStrategy(commonImpl, TypeEnum.QUX, SubTypeEnum.BAR)));
            registry.registerBean("quxBuzStrategy", DelegateStrategy.class, spec -> spec.prototype()
                    .lazyInit()
                    .primary()
                    .description("QuxBarStrategy bean")
                    .supplier(_ -> new DelegateStrategy(commonImpl, TypeEnum.QUX, SubTypeEnum.BUZ)));
        }
    }

Esto me permite registrar estrategias dinámicamente —incluso a partir de datos externos— y mantener el sistema abierto a nuevas combinaciones sin tocar la factory.

Ultimando Detalles

Como ahora tengo dos formas de registrar las estrategias, cree la property strategies.registrar para determinar si usar la nueva API o el registro clásico.

@SpringBootTest
class BeansdemoApplicationTests {
    @Autowired StrategiesFactory strategiesFactory;

    static Stream<Arguments> codeCombosAndExpectedStrategy() {
        return Stream.of(
                Arguments.of(TypeEnum.FOO, SubTypeEnum.BAR, FooBarStrategy.class),
                Arguments.of(TypeEnum.FOO, SubTypeEnum.BUZ, FooBuzStrategy.class),
                Arguments.of(TypeEnum.QUX, SubTypeEnum.BAR, QuxBarStrategy.class),
                Arguments.of(TypeEnum.QUX, SubTypeEnum.BUZ, QuxBuzStrategy.class)
        );
    }

    @ParameterizedTest
    @DisabledIf(expression = "#{'${strategies.registrar}' == 'true'}", loadContext = true)
    @MethodSource("codeCombosAndExpectedStrategy")
    void shouldGetByCodesCombo(TypeEnum typeEnum, SubTypeEnum subTypeEnum, Class<Strategy> expectedStrategyClass) {
        var actualStrategy = strategiesFactory.getStrategy(new Message(typeEnum, subTypeEnum));

        assertThat(actualStrategy).isInstanceOf(expectedStrategyClass);
    }

    static Stream<Arguments> codeCombosAndExpectedStrategyWhenRegistrar() {
        return Stream.of(
                Arguments.of(TypeEnum.FOO, SubTypeEnum.BAR, FooBarStrategy.class),
                Arguments.of(TypeEnum.FOO, SubTypeEnum.BUZ, FooBuzStrategy.class),
                Arguments.of(TypeEnum.QUX, SubTypeEnum.BAR, DelegateStrategy.class),
                Arguments.of(TypeEnum.QUX, SubTypeEnum.BUZ, DelegateStrategy.class)
        );
    }

    @ParameterizedTest
    @DisabledIf(expression = "#{'${strategies.registrar}' == 'false'}", loadContext = true)
    @MethodSource("codeCombosAndExpectedStrategyWhenRegistrar")
    void shouldGetByCodesCombo_registrar(TypeEnum typeEnum, SubTypeEnum subTypeEnum, Class<Strategy> expectedStrategyClass) {
        var actualStrategy = strategiesFactory.getStrategy(new Message(typeEnum, subTypeEnum));

        assertThat(actualStrategy).isInstanceOf(expectedStrategyClass);
    }
}

De esta manera, si el registrar está habilitado, verifico que las combinaciones QUX|BAR y QUX|BUZ sean instancias de DelegateStrategy. Si no, pruebo las clases concretas como antes.

Este patrón de estrategias con factory me permitió mantener un diseño limpio, flexible y fácil de extender.
Con las nuevas capacidades de registro programático en Spring 7, se abre una puerta interesante para generar beans dinámicos y reducir duplicación de código sin perder claridad.

Todo el código mostrado aquí esta disponible en éste proyecto en mi Github 🚀🚀

Te invito a contarme que opinas, como lo habrías hecho vos o si queres que profundice en alguno de los puntos mencionados en los comentarios! 👇

Por qué empecé un blog?

Federico Herrera — Wed, 12 Nov 2025 11:52:32 +0000

Que tal! Soy Fede Herrera 👋

Un desarrollador Java con varios años de experiencia en la industria. He trabajado para empresas gigantes, como son Globant, EY, Disney Media y BBVA Argentina. Solo para dar un poco de contexto sobre quién soy antes de empezar.

Hay varios motivos por los que me interesa escribir. El principal, y probablemente el que más se repite entre quienes deciden exponer sus ideas, es crear una marca. Ganar alcance, interacciones y tráfico online es, sin duda y sin descubrir nada nuevo, una de las formas más fáciles de construir conexiones.

Una segunda razón importante es que hay poco contenido técnico en español. Tengo bastante experiencia en el área y, aunque mi nivel de inglés es alto desde antes de empezar mi carrera, siempre fue mucho más fácil encontrar buenos posts o guías si buscabas directamente en inglés —al menos antes de la explosión de la IA.

En tercer lugar, no creo que hacer TikToks sea para mí (al menos por ahora). Se me cruzó la idea cuando pensaba cómo empezar, inspirada en un video que se le hizo viral a mi hermano y lo motivó a crear más contenido. No lo descarto a futuro: es una plataforma enorme y, aunque no sea la primera opción educativa de nadie, un video corto y bien hecho siempre atrapa.

En fin, este es mi primer post para dar una especie de kickoff a mi aventura en esta plataforma.

Mi idea es compartir contenido principalmente sobre Java, Spring Framework y Cloud, tal vez algo de DevOps que estoy empezando a aprender y Kubernetes. Soy un apasionado del testing, así que no se sorprendan de ver algún post sobre testing unitario y de integración, TDD, Mockito, WireMock, MockServer y Testcontainers.

Si leíste hasta aquí, ¡muchas gracias! 🙌
Es una lectura corta, pero para mí significa mucho que te hayas quedado.
Si te interesa, puedes conectar conmigo en LinkedIn y GitHub.

¡Espero leernos pronto! 👋