No content

Como desacoplar Componentes Aplicando DI e IoC com Spring e Kotlin

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

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

Qual a motivação para essa talk?

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

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

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

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.

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.

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

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

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.

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

Que tal começar resolver esse desafio?

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

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

Use Case

Controller

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

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

No content

Ciclo de vida do Container Spring

Automagicamente!!!!

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

No content

No content

E é isso aí > Let's code

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

Somos remotos! Liberdade para a sua carreira te empoderar!