Como Postergar Implementações sem Comprometer Seu Código: Exemplos com Spring Security e Filas

Neste vídeo, você vai ver como postergar a implementação de tecnologias em seu projeto sem comprometer a qualidade do código.
Eu compartilho dois exemplos práticos que mostram como preparar o código para integrações futuras. Os exemplos são em cima do Spring Security e da integração do Spring com Message Brokers.
Veremos como organizar o código de forma que ele esteja pronto para evoluções, permitindo decisões mais informadas no momento certo.
Se você quer saber como adiar a implementação de decisões técnicas, sem quebrar seu código no futuro, considero que este vídeo pode ajudar :).
Sobre a Jornada Dev Eficiente
A Jornada Dev + Eficiente é um treinamento cujo propósito é acelerar seu desenvolvimento como uma pessoa cada vez mais especializada em Design e Arquitetura de Software.
A comunidade é mantida por Alberto, Maurício Aniche e Rafael Ponte.
Para saber mais, acesse em deveficiente.com
Saiba mais sobre Alberto, Aniche e Rafael
Github Alberto: github.com/asouza
Twitter Alberto: / alberto_souza
Github Aniche: github.com/mau...
Twitter Aniche: / mauricioaniche
Github Rafael: github.com/rponte
Twitter Rafael: / rponte
Instagram Dev Eficiente: / deveficiente

[@alexncosta]

Ouvindo sua explicação Alberto, fiquei pensando a respeito de duas situações que vejo muito acontecer, uma delas é justamente o ponto que você colocou de postergar determinadas decisões, nesse ponto, quase todo tutorial ou curso que já vi, começa com a instalação do conjunto de ferramentas, bibliotecas, frameworks e tudo mais, as vezes naquele momento você nem precisa daquilo instalado. Outro ponto que vejo, é que sua explicação me fez lembrar muito de um dos propósitos de arquiteturas como a clean arch e hexagonal, quando coloca na camada de Infraestrutura tudo que diz respeito a tecnologias e quando você decide, por exemplo, mudar o broker que está utilizando para mensageria, a arquitetura do seu software torna mas fácial a inclusão/adaptação do novo broker que será adotado. No primeiro ponto, a gente evita se preocupar com aquilo que ainda não precisamos e no segundo facilita a adoção de novas tecnologias que decidimos utilizar depois de implementado o software.

[@DevEficiente]

opa, sobre adicionar as dependências, acho mais ok. Nem todo projeto usa a mesma coisa, mas fica colocando só o que precisa estritamente considero um esforço desnecessário. A não ser que tenha alguma questão envolvida que não estou enxergando aqui. Sobre as referências arquiteturais, é por aí mesmo. O que acho que mais pega é que para postergar direito você precisa ter uma boa ideia de como a coisa funciona, caso contrário você pode sair com um comportamento público que é pouco adaptável a um novo cenário.