Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Escaping from the framework

Escaping from the framework

Slides de apoio da minha apresentação sobre Clean Architecture. Apresentação oferecida nos seguintes eventos:

- iMasters Intercon 2016
- GDGSP Devfest 2016
- OpenSanca DevConf 2017
- ICMC/USP Semcomp20

Ubiratan Soares
PRO

October 22, 2016
Tweet

More Decks by Ubiratan Soares

Other Decks in Programming

Transcript

  1. ESCAPING FROM
    THE FRAMEWORK
    guided by Clean Archictecture
    Ubiratan Soares
    Agosto / 2017

    View Slide

  2. ERA UMA VEZ UM
    DESENVOLVEDOR ...

    View Slide

  3. QUE PRECISAVA
    CRIAR O NOVO APP
    QUE MUDARIA TUDO

    View Slide

  4. ELE FOI DIRETO NA
    FONTE PARA SABER
    COMO FAZER

    View Slide

  5. View Slide

  6. View Slide

  7. View Slide

  8. ALGUNS MESES
    DEPOIS, O MUNDO NÃO
    SERIA MAIS O MESMO

    View Slide

  9. View Slide

  10. PORÉM …

    View Slide

  11. SEM PAUSA PARA REFACTOR

    View Slide

  12. QUAIS OS
    PROBLEMAS NO
    MÉDIO PRAZO ???

    View Slide

  13. TEM PELO MENOS UM UNIT TEST NO PROJETO?

    View Slide

  14. FAT MODELS / FAT VIEWS / FAT CONTROLLERS

    View Slide

  15. ACOPLAMENTO

    View Slide

  16. UM SOFTWARE
    ENVIESADO PELOS
    DADOS …

    View Slide

  17. {
    “name”: “José da Silva”,
    “age”: 33

    } USER
    String name;
    int age;

    View Slide

  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)

    View Slide

  19. App (Visão Romântica)

    View Slide

  20. CONTROLLER CONTROLLER
    CONTROLLER
    CONTROLLER
    CONTROLLER
    CONTROLLER
    CONTROLLER
    CONTROLLER
    CONTROLLER
    CONTROLLER
    CONTROLLER
    CONTROLLER
    App (Visão Real)
    SINGLETON

    View Slide

  21. View Slide

  22. WTF ?????

    View Slide

  23. View Slide

  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?

    View Slide

  25. SEUS
    SONHOS

    View Slide

  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

    View Slide

  27. COMO FAZER UM
    PROJETO DE SOFTWARE
    SUSTENTÁVEL ???

    View Slide

  28. CONSTRUIR PARA PARA ESCALAR

    View Slide

  29. O QUE É
    ARQUITETURA DE
    SOFTWARE ???

    View Slide

  30. MVP
    MVVM
    VIPER
    FLUX REDUX
    DDD
    MVC

    MVI

    View Slide

  31. View Slide

  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

    View Slide

  33. DATA-CENTRIC ARCHITECTURE
    UI
    BUSINESS LOGIC (MODEL + CONTROL)
    DATABASE NETWORKING ETC

    View Slide

  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

    View Slide

  35. https://vimeo.com/43612849

    View Slide

  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

    View Slide

  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)

    View Slide

  38. DOMAIN-CENTRIC ARCHITECTURE
    PRESENTATION
    LAYER
    DOMAIN
    LAYER
    DATA
    LAYER
    DB
    REST
    ETC
    UI
    . . .

    View Slide

  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

    View Slide

  40. USECASE
    REST GATEWAY
    PRESENTER
    VIEW CONTRACT
    PLATAFORM CONTROLLER
    DEFINIR
    FRONTEIRAS
    SOURCE CONTRACT
    ENTITY
    APPLICATION
    CORE
    Associação
    Dependência

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  46. COMO TESTAR?

    View Slide

  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)

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  51. CONCLUINDO

    View Slide

  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

    View Slide

  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)

    View Slide

  54. UBIRATAN
    SOARES
    Computer Scientist by ICMC/USP
    Software Engineer, curious guy
    Google Developer Expert for Android
    Teacher, speaker, etc, etc

    View Slide

  55. https://speakerdeck.com/ubiratansoares/escaping-from-the-framework

    View Slide

  56. OBRIGADO
    @ubiratanfsoares
    ubiratansoares.github.io
    https://br.linkedin.com/in/ubiratanfsoares

    View Slide