Slide 1

Slide 1 text

No content

Slide 2

Slide 2 text

Como desacoplar Componentes Aplicando DI e IoC com Spring e Kotlin

Slide 3

Slide 3 text

Fabiano Góes Engenheiro de Software backend na Cora [email protected] /fabianogoes /fabianogoes

Slide 4

Slide 4 text

➢ Human ➢ Não sou dono da verdade ➢ Feedback

Slide 5

Slide 5 text

Qual a motivação para essa talk?

Slide 6

Slide 6 text

Design Patterns Clean Architecture Clean Code Frameworks Libs Negócio Linguagem SOLID

Slide 7

Slide 7 text

A boa notícia é que, em muitos casos, os conceitos já estão sendo usados, mas nem sabemos.

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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.

Slide 10

Slide 10 text

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.

Slide 11

Slide 11 text

Porque desacoplar componentes? ● Funcionou. Por que mexer? ● Porque Refatorar? ● Teste é para os fracos. Don't want

Slide 12

Slide 12 text

O conceito base para essa melhoria é: Classes devem ter alta coesão e baixo acoplamento!

Slide 13

Slide 13 text

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.

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

Que tal começar resolver esse desafio?

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

As implementações de Repositório (SRP) Princípio da Responsabilidade única S do S.O.L.D

Slide 18

Slide 18 text

Use Case

Slide 19

Slide 19 text

Controller

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

Foi aí que o Spring brilhou e talvez você nem percebeu?

Slide 22

Slide 22 text

No content

Slide 23

Slide 23 text

Ciclo de vida do Container Spring

Slide 24

Slide 24 text

Automagicamente!!!!

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

No content

Slide 27

Slide 27 text

No content

Slide 28

Slide 28 text

E é isso aí > Let's code

Slide 29

Slide 29 text

Obrigada! { println("Seja Cora!") }

Slide 30

Slide 30 text

Somos remotos! Liberdade para a sua carreira te empoderar!