Baixar para ler offline
Carregado porRafael Capuano
Introducao a Clean Architecture
O documento apresenta a Clean Architecture, popularizada por Robert C. Martin, destacando a unificação de conceitos arquiteturais que permitem a independência de frameworks e a testabilidade do código. Ele descreve os componentes essenciais, como entidades, casos de uso e adaptadores de interface, enfatizando a importância de seguir princípios de responsabilidade única e inversão de dependências. A Clean Architecture é adaptável, mas deve manter a independência entre camadas para evitar problemas nas aplicações.
Introducao a Clean Architecture
- 1.
- 2. Hello World! Rafael Capuano Desenvolvedorback-end desde 2011 (há 4 anos na Praxio) Um apaixonado por programação, fã de futebol, movido pelo desafio de viver... https://medium.com/@rafacapuano
- 3.
- 4. • Hexagonal Architecture(Ports & Adapters) • Onion Architecture • Screaming Architecture • DCI • BCE 4
- 5. • Separação deresponsabilidades • Independência de frameworks, bancos de dados, UI ou qualquer agente externo • Redução do custo de mudança • Código testável • Facilidade para entender o que o sistema faz 5
- 6. 6 Clean Architecture aoresgate...
- 7.
- 8. 8 • Popularizado porRobert C. Martin (Uncle Bob) • Unificação dos conceitos arquiteturais já existentes • O sistema é visto como um conjunto de camadas que interagem seguindo “The Dependency Rule”
- 9.
- 10. “The outer circlesare mechanisms. The inner circles are policies” 10 Uncle Bob “This rule (The Dependency Rule) says that source code dependencies can only point inwards”
- 11.
- 12.
- 13. • Conceito existenteno DDD (Domain Driven Design) • Representam os objetos do domínio • São conduzidas pelo negócio, nunca por frameworks 13
- 14.
- 15. • Descrevem oque o sistema faz • Concentram as regras de negócio da aplicação • Definido como um conjunto de etapas (interações) para se alcançar o objetivo • Ao escrever as classes, devemos dar atenção ao Single Responsability Principle do SOLID 15
- 16.
- 17. • Converte dadosdo Use Case para agentes externos (como a Web, por exemplo) e vice- versa • Composto por componentes MVC já conhecidos, como Controllers e Views, e os Repositórios para acesso ao banco de dados • O código deve ser o mais simples possível, sem lógica de negócio 17
- 18.
- 19. • É acomposição dos agentes externos (detalhes), como Web, banco de dados e frameworks • Não devem influenciar os modelos de negócio 19
- 20.
- 21. Dependency Inversion • Acomunicação entre as camadas deve se dar por abstrações (interfaces) Data Transfer Objects • Dados devem ser transferidos entre as camadas no modelo adequado para elas 21
- 22. Não existe balade prata; Como qualquer conceito, você pode adaptá-lo à sua realidade, mas cuidado para não que quebrar o princípio de independência entre as camadas do seu projeto. Na dúvida, siga o SOLID, converse com o time e acredite em você! 22
- 23.
- 24. • Aplicando cleanarchitecture no back-end • Aplicando clean architecture no front-end 24
- 25.
- 26. 26 Por enquanto ésó... Obrigado!