Tak sobre "Como desacoplar Componentes aplicando DI e IoC com Kotlin e Spring"ministrada no TDC de 2022

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?

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

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.

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!