Escaping from the framework

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

ERA UMA VEZ UM DESENVOLVEDOR ...

Slide 3

Slide 3 text

QUE PRECISAVA CRIAR O NOVO APP QUE MUDARIA TUDO

Slide 4

Slide 4 text

ELE FOI DIRETO NA FONTE PARA SABER COMO FAZER

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

No content

Slide 10

Slide 10 text

PORÉM …

Slide 11

Slide 11 text

SEM PAUSA PARA REFACTOR

Slide 12

Slide 12 text

QUAIS OS PROBLEMAS NO MÉDIO PRAZO ???

Slide 13

Slide 13 text

TEM PELO MENOS UM UNIT TEST NO PROJETO?

Slide 14

Slide 14 text

FAT MODELS / FAT VIEWS / FAT CONTROLLERS

Slide 15

Slide 15 text

ACOPLAMENTO

Slide 16

Slide 16 text

UM SOFTWARE ENVIESADO PELOS DADOS …

Slide 17

Slide 17 text

{ “name”: “José da Silva”, “age”: 33 … } USER String name; int age; …

Slide 18

Slide 18 text

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)

Slide 19

Slide 19 text

App (Visão Romântica)

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

No content

Slide 22

Slide 22 text

WTF ?????

Slide 23

Slide 23 text

No content

Slide 24

Slide 24 text

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?

Slide 25

Slide 25 text

SEUS SONHOS

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

CONSTRUIR PARA PARA ESCALAR

Slide 29

Slide 29 text

O QUE É ARQUITETURA DE SOFTWARE ???

Slide 30

Slide 30 text

MVP MVVM VIPER FLUX REDUX DDD MVC … MVI

Slide 31

Slide 31 text

No content

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

https://vimeo.com/43612849

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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)

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

COMO TESTAR?

Slide 47

Slide 47 text

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)

Slide 48

Slide 48 text

EVITE O SANDUÍCHE UNEEDED ENTITY UNEEDED USECASE UNEEDED DOMAIN SERVICE PRESENTER • Boillerplate desnecessário (código e testes) • Díﬁcil de identiﬁcar no médio prazo • Origens típicas : Adotar o mesmo modelo de layers em todo o lugar possível Tentar prever o futuro

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

ORGANIZAÇÃO FUNCIONAL • Intenção explícita • Localidade espacial • Fácil Navegação • Fácil identiﬁcar onde estão dependências de ferramentas • Pode quebrar convenções de frameworks • Pode quebrar scaffolding / ﬁle 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

Slide 51

Slide 51 text

CONCLUINDO

Slide 52

Slide 52 text

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; identiﬁcar as fronteiras é fácil, identiﬁcar domínio e casos de uso pode ser mais difícil • Não há ROI imediato, nem Silver Bullets

Slide 53

Slide 53 text

CONSIDERAÇÕES FINAIS • Clean Architecture tem a ver com idéias de organizar as coisas e não com fórmulas prontas • Deﬁna 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)

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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