DevConf | Escaping from the framework, guided by Clean Architecture @Ubiratan Soares

Primeiro Evento organizado pelo Opensanca se trata do DevConf, tivemos a participação do Ubiratan Soares (https://br.linkedin.com/in/ubiratanfsoares) abordando sobre Clean Architecture.

Transcript

1. ESCAPING FROM THE FRAMEWORK guided by Clean Archictecture Ubiratan Soares Maio / 2017
2. ERA UMA VEZ UM DESENVOLVEDOR ...
3. QUE PRECISAVA CRIAR O NOVO APP QUE MUDARIA TUDO
4. ELE FOI DIRETO NA FONTE PARA SABER COMO FAZER
8. ALGUNS MESES DEPOIS, O MUNDO NÃO SERIA MAIS O MESMO
10. PORÉM …
11. SEM PAUSA PARA REFACTOR
12. QUAIS OS PROBLEMAS NO MÉDIO PRAZO ???
13. TEM PELO MENOS UM UNIT TEST NO PROJETO?
14. FAT MODELS / FAT VIEWS / FAT CONTROLLERS
15. ACOPLAMENTO
16. UM SOFTWARE ENVIASADO PELOS DADOS …
17. { “name”: “José da Silva”, “age”: 33 … } USER String name; int age; …
18. FRAMEWORK VIEW/CONTROLLER RestManager mngr = … DAOBridge bridge = … DAOBridge RestManager Model A Model B Model C Model D frameworkview.setData(model.attribute) MODEL api.getModel(callback) modelDAO.query(args)
19. App (Visão Romântica)
20. CONTROLLER CONTROLLER CONTROLLER CONTROLLER CONTROLLER CONTROLLER CONTROLLER CONTROLLER CONTROLLER CONTROLLER CONTROLLER CONTROLLER App (Visão Real) SINGLETON
22. WTF ?????
24. COMO REPRODUZIR ESSE ERRO? COMO CORRIGIR ESSE ERRO? COMO GARANTIR QUE NÃO OCORRERÁ NOVAMENTE? COMO SABER SE A CORREÇÃO NÃO GEROU OUTROS ERROS?
25. SEUS SONHOS
26. MALES DO ACOPLAMENTO • Não torna a aplicação portável • Vincula a aplicação a frameworks e ferramentas • Torna difícil testar regras de negócio e comportamentos esperados • Apodrece o código a médio prazo
27. COMO FAZER UM PROJETO DE SOFTWARE SUSTENTÁVEL ???
28. CONSTRUIR PARA PARA ESCALAR
29. O QUE É ARQUITETURA DE SOFTWARE ???
30. MVP MVVM VIPER FLUX REDUX DDD MVC … MVI
32. ARQUITETURA DE SOFTWARE • Uma maneira de organizar as coisas • Estilo de projeto, definido e defendido pelo time • Estilos sobre as definições de componentes, camadas e relacionamentos • Boa arquitetura : facilidade de manutenção e extensão, legibilidade, entendimento do que acontece, testabilidade, flexível • Arquitetura ruim : difícil manutenção, rígida, frágil, difícil de se encontrar o que se precisa, sem testes, alta complexidade
33. DATA-CENTRIC ARCHITECTURE UI BUSINESS LOGIC (MODEL + CONTROL) DATABASE NETWORKING ETC
34. UI Networking Entities Usecases Presenters Gateways DB Drivers Device Adapters Interactors DOMAIN CENTRIC (Clean) Data Access (External World REST, DB, etc) UI Bussiness Logic DATA CENTRIC
35. https://vimeo.com/43612849
36. CLEAN ARCHICTECTURE • R.O.I em continuidade a longo prazo • Favorece práticas como S.O.L.I.D e testabilidade • Deixa explícitas as regras de negócio • Database é detalhe • REST e networking são detalhes • UI rendering e frameworks são detalhes • Entidades (conceitos) são essenciais • Casos de uso são essenciais • Contratos de apresentação e de origem dos dados são essenciais Motivações Distinção entre essencial e detalhes
37. DEPENDENCY RULE UI Networking Entities Usecases Presenters Gateways DB Drivers Device Adapters Interactors Camada mais externa em geral depende de um contrato com a camada mais interna Camadas mais externas mais próximas às fronteiras da aplicação Camadas ao centro contém as regras de negócio (o que a aplicação faz)
38. DOMAIN-CENTRIC ARCHITECTURE PRESENTATION LAYER DOMAIN LAYER DATA LAYER DB REST ETC UI . . .
39. TRÊS GRANDES PILARES • O comportamento da sua aplicação deveria depender exclusivamente da linguagem, e não de frameworks e ferramentas • Sua aplicação se relaciona com comportamentos, como por exemplo, interfaces para entregar e receber dados : frameworks implementam esses comportamentos • O núcleo da aplicação deve ser 100% testável; isso inclui TODAS as regras de negócio
40. USECASE REST GATEWAY PRESENTER VIEW CONTRACT PLATAFORM CONTROLLER DEFINIR FRONTEIRAS SOURCE CONTRACT ENTITY APPLICATION CORE Associação Dependência
41. DOMÍNIO DA APLICAÇÃO • Indica aquilo que a aplicação faz • Casos de uso sobre entidades do domínio (modelos), que são as representações dos conceitos para a aplicação (não para a UI, nem para sistemas externos) • Exemplos típicos : • AddToBasket.with(Item) • RetrieveCustomerData.perform( ) • PerformPurchase.with(Review) • etc • Casos de uso fazem muito sentido quando existem oportunidades explícitas de reúso
42. USECASE 01 PRESENTER VIEW CONTRACT PLATAFORM CONTROLLER (passive delivery) USECASE 02 VIEW MODEL ISOLANDO A INTERFACE Associação Dependência Application Boundary INPUT MODEL ENTITY A ENTITY B
43. USECASE SOURCE CONTRACT REST IMPLEMENTATION (delivery mechanism) REQUEST MODEL Application Boundary ISOLANDO I/O DAO / ORM / etc (delivery mechanism) RESPONSE MODEL TUPLE MODEL QUERY MODEL ENTITY A ENTITY B Associação Dependência SOURCE CONTRACT
44. SEPARE REPRESENTAÇÕES String description = “Blah” String date = “2010-02-26T19:35:24Z” int step = 2 String description = “Blah” LocalDateTime dateTime = (language representation) TrackingStep currentStep = (enum) String description = “Blah” String formattedDate = “26/02/2010” String currentStep = “Concluído” Response Model Domain Model (Entity) ViewModel
45. CONECTANDO CAMADAS Estratégia Vantagens Desvantagens Síncrono Método mais simples Casos de uso não podem executar em paralelo; restrições de contexto Callbacks Geralmente suportados pela própria linguagem Difícies de debuggar com concorrência e/ou múltiplas camadas; problemas com ciclo de vida de objetos Barramento de eventos Resolvem Callback Hell Normalmente sem suporte a threading, mais difícil de debuggar e testar que callbacks Reactive Programming Assincronia e concorrência com API ao estilo síncrono; fáceis de testar Difíceis de aprender, não necessariamente fáceis de debuggar
46. COMO TESTAR?
47. UNIT TESTS (Mocked Contract) FUNCTIONAL UI TESTS INTEGRATION TESTS USECASE EXTERNAL WORLD ADAPTER PRESENTER VIEW CONTRACT PLATAFORM CONTROLLER SOURCE CONTRACT ENTITY INTEGRATION TESTS (DOUBLES) UNIT ACCEPTANCE E2E INTEGRATION UNIT TESTS (Mocked Contract + Mocked Usecase)
48. EVITE O SANDUÍCHE UNEEDED ENTITY UNEEDED USECASE UNEEDED DOMAIN SERVICE PRESENTER • Boillerplate desnecessário (código e testes) • Díficil de identificar no médio prazo • Origens típicas : Adotar o mesmo modelo de layers em todo o lugar possível Tentar prever o futuro
49. ORGANIZE POR CONTEXTO typical-packaging ├── activies ├── adapters ├── fragments ├── networking ├── ... ├── services ├── storage ├── util └── widgets clear-intentions—packaging ├── customer ├── checkout │ ├── basket │ ├── purchase │ └── review ├── orders ├── products ├── ... ├── push └── shared VS
50. ORGANIZAÇÃO FUNCIONAL • Intenção explícita • Localidade espacial • Fácil Navegação • Fácil identificar onde estão dependências de ferramentas • Pode quebrar convenções de frameworks • Pode quebrar scaffolding / file templates / etc • Testes deveriam seguir mesma organização, mas podem morar em diretórios diferentes (replicação manual) • Normalmente o projeto nasce organizado por categorias : difícil migração Benefícios Potenciais problemas
51. CONCLUINDO
52. DIFICULDADES TÍPICAS • “É preciso escrever muito código para ter algo realmente funcionando” • Flerte constante com over-engineering • Decisões de quantas e quais camadas adotar e quais são as apropriadas dependem de contexto (time, projeto e negócio) • Projetos em andamento (tipicamente) não nascem nessa estrutura e precisam ser evoluídos; identificar as fronteiras é fácil, identificar domínio e casos de uso pode ser mais difícil • Não há ROI imediato, nem Silver Bullets
53. CONSIDERAÇÕES FINAIS • Clean Architecture tem a ver com idéias de organizar as coisas e não com fórmulas prontas • Defina sua arquitetura de maneira a deixar claras as intenções do seu código e da sua aplicação • Sua aplicação é um grande roteador entre agentes de interesse, separe o essencial (o que ela é) dos detalhes (que podem ser substituídos) • Comece pelo simples, extraindo comportamentos nas fronteiras do(s) framework(s) e fazendo inversão de controle o(s) mesmo(s)
54. UBIRATAN SOARES Computer Scientist by ICMC/USP Software Engineer @ luizalabs Google Developer Expert for Android Teacher, speaker, etc, etc
55. https://speakerdeck.com/ubiratansoares/escaping-from-the-framework
56. OBRIGADO @ubiratanfsoares ubiratansoares.github.io https://br.linkedin.com/in/ubiratanfsoares