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

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 full-size slide

  2. ERA UMA VEZ UM
    DESENVOLVEDOR ...

    View full-size slide

  3. QUE PRECISAVA
    CRIAR O NOVO APP
    QUE MUDARIA TUDO

    View full-size slide

  4. ELE FOI DIRETO NA
    FONTE PARA SABER
    COMO FAZER

    View full-size slide

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

    View full-size slide

  6. SEM PAUSA PARA REFACTOR

    View full-size slide

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

    View full-size slide

  8. TEM PELO MENOS UM UNIT TEST NO PROJETO?

    View full-size slide

  9. FAT MODELS / FAT VIEWS / FAT CONTROLLERS

    View full-size slide

  10. UM SOFTWARE
    ENVIESADO PELOS
    DADOS …

    View full-size slide

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

    } USER
    String name;
    int age;

    View full-size slide

  12. 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 full-size slide

  13. App (Visão Romântica)

    View full-size slide

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

    View full-size slide

  15. 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 full-size slide

  16. 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 full-size slide

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

    View full-size slide

  18. CONSTRUIR PARA PARA ESCALAR

    View full-size slide

  19. O QUE É
    ARQUITETURA DE
    SOFTWARE ???

    View full-size slide

  20. MVP
    MVVM
    VIPER
    FLUX REDUX
    DDD
    MVC

    MVI

    View full-size slide

  21. 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 full-size slide

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

    View full-size slide

  23. 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 full-size slide

  24. https://vimeo.com/43612849

    View full-size slide

  25. 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 full-size slide

  26. 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 full-size slide

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

    View full-size slide

  28. 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 full-size slide

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

    View full-size slide

  30. 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 full-size slide

  31. 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 full-size slide

  32. 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 full-size slide

  33. 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 full-size slide

  34. 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 full-size slide

  35. COMO TESTAR?

    View full-size slide

  36. 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 full-size slide

  37. 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 full-size slide

  38. 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 full-size slide

  39. 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 full-size slide

  40. 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 full-size slide

  41. 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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide