Como desacoplar Componentes aplicando DI e IoC com Kotlin e Spring

Esse Slide foi utilizado em minha Talk do TDC Connections 2022 na sala da Cora.

A idéia é mostrar como muitos conceitos que vemos em chuvas de palavras, já utilizamos em nosso dia-a-dia no desenvolvimento Java/Kotlin com Spring, além de demonstrar como funciona o ciclo de vida de componentes no Spring.

Utilizei este repositório no Github: https://github.com/fabianogoes/tdc2022-demo-order

Transcript

2. Como desacoplar Componentes Aplicando DI e IoC com Spring e Kotlin
3. Fabiano Góes Engenheiro de Software backend na Cora fabiano@cora.com.br /fabianogoes /fabianogoes
4. ➢ Human ➢ Não sou dono da verdade ➢ Feedback
5. Qual a motivação para essa talk?
6. Design Patterns Clean Architecture Clean Code Frameworks Libs Negócio Linguagem SOLID
7. A boa notícia é que, em muitos casos, os conceitos já estão sendo usados, mas nem sabemos.
8. Acoplamento Um software com Forte Acoplamento torna-se um problema na hora de mantê-lo devido ao alto grau de interdependência entre seus componentes
9. Um exemplo de como violar vários princípios ❌ Alta coesão. ❌ Baixo acoplamento. ❌ Responsabilidade única. ❌ Princípio da Inversão de Dependência. ❌ Abertos para extensão, mas fechados para modificação.
10. Como podemos melhorar isso? ✓ Controller deveria apenas controlar a entrada e saída de dados. ✓ Controller não deveria saber sobre Repositório. ✓ Controller não deveria saber de como construir um Pedido. ✓ Precisamos conseguir testar nossa regra de pedido isoladamente. ✓ Precisamos conseguir configurar um banco de dados para cada ambiente.
11. Porque desacoplar componentes? • Funcionou. Por que mexer? • Porque Refatorar? • Teste é para os fracos. Don't want
12. O conceito base para essa melhoria é: Classes devem ter alta coesão e baixo acoplamento!
13. Não é fácil testar código acoplado e sem coesão! Se o seu código está difícil de ser testado isoladamente, pode ser um cheiro de que ele está com alto acoplamento e baixa coesão. E isso vai ter um custo alto e o seu castelo de cartas pode cair a qualquer momento.
14. Princípios que podemos utilizar: Princípio da Responsabilidade única S do S.O.L.D Uma classe deve ter um, e somente um, motivo para mudar. Inversão de Controle Um padrão muito utilizado em POO para delegar a responsabilidade do ciclo de vida de componentes. Princípio da Inversão de Dependência D do S.O.L.I.D Dependa de abstrações e não de implementações SRP IoC DIP
15. Que tal começar resolver esse desafio?
16. Começando aplicando o princípio (DIP) Princípio da Inversão de Dependência D do S.O.L.I.D - Dependa de abstrações e não de implementações
17. As implementações de Repositório (SRP) Princípio da Responsabilidade única S do S.O.L.D
18. Use Case
19. Controller
20. E o IoC cadê? onde ele entrou nessa história toda? Inversão de Controle Um padrão muito utilizado em POO para delegar a responsabilidade do ciclo de vida de componentes. IoC
21. Foi aí que o Spring brilhou e talvez você nem percebeu?
23. Ciclo de vida do Container Spring
24. Automagicamente!!!!
25. Estrutura Domínio isolado e protegido das bordas de entrada e saída que envolvem tecnologia e não negócio. Portas são as Interfaces onde o UseCase conhece e executa alguma coisa fora do negócio. Infra é a parte de tecnologia e acesso externos ao domínio, como: Banco de Dados, Comunicação Assíncrona e etc. Web é a camada de input da aplicação
28. </ E é isso aí > Let's code
29. Obrigada! { println("Seja Cora!") }
30. Somos remotos! Liberdade para a sua carreira te empoderar!