1) O documento discute os princípios da Arquitetura Limpa, incluindo independência de responsabilidades, testabilidade e independência de frameworks. 2) Apresenta diferentes abordagens de organização de projetos como camadas, recursos, portas e adaptadores e componentes. 3) Pede para colocar os princípios em prática no código e conclui a apresentação.

1. Izabela Guerreiro
Arquitetura
Limpa

2. Izabela Guerreiro
Desenvolvedora Backend
izaguerreiro
izaguerreiro
/in/izabela-dos-santos-guerreiro/
www.izaguerreiro.me
Quem sou eu?

3. AGENDA
Arquitetura Limpa
Organização de
projeto
01
02
03
04
Bora pro código
Conclusão

4. Arquitetura Limpa
01

5. "Uma boa arquitetura deve possibilitar que o sistema nasça como
monolito, seja implantado em um único arquivo e, então cresça
como um conjunto de unidades independentemente implantáveis,
incluindo serviços independentes e/ou microsserviços. Mais
tarde, com as mudanças, deve permitir a reversão dessa
progressão e o retorno ao estado monolito."
Robert C. Martin

6. ● Primeira publicação no post do Uncle Bob em 2012
● Primeira publicação do livro em 2017
● Principal objetivo separação de responsabilidade
● Princípios SOLID
Arquitetura Limpa

7. ● Independência de framework
● Testabilidade
● Independência da UI
● Independência de banco de dados
● Independência de qualquer agência externa
Principais características

9. Organização de projeto
02

10. ● A mais simples abordagem de design
● Segundo Martin Fowler, é uma boa maneira de começar
● Maneira rápida de fazer funcionar sem muita complexidade
Desvantagens:
● Quando o software escala e ganha complexidade pode demandar a criação de mais
camadas
● As camadas não dizem nada sobre o domínio do negócio
● A camada de web pode se comunicar diretamente com a camada data
Pacote por camada

11. Pacote por recurso
● Um único pacote
● Pacote com base nos recursos relacionados ao domínio
● Potencialmente mais fácil encontrar o código
● OBS: Nenhum item fora do pacote pode acessar as informações sem passar pela View
(Controller)

12. Portas e adaptadores
● Separada entre dentro (domínio) e fora (infraestrutura)
● Dentro: contém tudo que é relacionado ao domínio
● Fora: contém as interações externas (UI, banco de dados, etc..)
● Principal regra é o que está fora depende do que está dentro e nunca o contrário

13. Pacote por componente
● Abordagem híbrida para todas as descritas anteriormente
● Objetivo as responsabilidade um componente em um único pacote
● Somente uma entrada para o componente

14. Bora pro código
03

15. Conclusão
04

16. CREDITS: This presentation template was created by Slidesgo, including
icons by Flaticon, and infographics & images by Freepik.
Please keep this slide for attribution.
That's all folks!