ESCAPING FROM
THE FRAMEWORK
guided by Clean Archictecture
Ubiratan Soares
Outubro/2016
ERA UMA VEZ UM
DESENVOLVEDOR ...
UM LUGAR COMUM
• Documentações oficiais enviesam acoplamento
• Senso comum direciona para arquiteturas orientadas a dados
•...
FRAMEWORK
VIEW/CONTROLLER
RestManager mngr = …
DAOBridge bridge = …
DAOBridge
RestManager
Model A
Model B
Model C
Model D
...
App (Visão Romântica)
CONTROLLER CONTROLLER
CONTROLLER
CONTROLLER
CONTROLLER
CONTROLLER
CONTROLLER
CONTROLLER
CONTROLLER
CONTROLLER
CONTROLLER
C...
WTF ?????
COMO REPRODUZIR ESSE ERRO?
COMO CORRIGIR ESSE ERRO?
COMO GARANTIR QUE NÃO OCORRERÁ
NOVAMENTE?
COMO SABER SE A CORREÇÃO NÃO...
MALES DO ACOPLAMENTO
• Não torna a aplicação portável
• Vincula a aplicação a frameworks e ferramentas
• Torna difícil tes...
COMO ESCAPAR
DO FRAMEWORK ?
ARQUITETURA DE SOFTWARE
• Uma maneira de organizar as coisas
• Estilos sobre as definições de componentes, camadas e
relaci...
DATA-CENTRIC ARCHITECTURE
UI
BUSINESS LOGIC (MODEL + CONTROL)
DATABASE NETWORKING ETC
UI
Networking
Entities
Usecases
Presenters
Gateways
DB
Drivers
Device
Adapters
Interactors
DOMAIN CENTRIC (aka Clean)
Data...
https://vimeo.com/43612849
CLEAN ARCHICTECTURE
• R.O.I em continuidade a
longo prazo
• Favorece práticas como
S.O.L.I.D e testabilidade
• Deixa explí...
DEPENDENCY
RULE
UI
Networking
Entities
Usecases
Presenters
Gateways
DB
Drivers
Device
Adapters
Interactors
Camada mais ext...
DOMAIN-CENTRIC ARCHITECTURE
PRESENTATION
LAYER
DOMAIN
LAYER
DATA
LAYER
DB
REST
ETC
UI
. . .
TRÊS GRANDES PILARES
• O comportamento da sua aplicação deveria depender exclusivamente
da linguagem, e não de frameworks ...
USECASE
REST GATEWAY
PRESENTER
VIEW CONTRACT
PLATAFORM CONTROLLER
DEFINIR
FRONTEIRAS
SOURCE CONTRACT
ENTITY
APPLICATION
CO...
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 r...
USECASE 01
PRESENTER
VIEW CONTRACT
PLATAFORM CONTROLLER
(passive delivery)
USECASE 02
VIEW MODEL
ISOLANDO A
INTERFACE
Asso...
USECASE
SOURCE CONTRACT
REST IMPLEMENTATION
(delivery mechanism)
REQUEST MODEL
Application
Boundary
ISOLANDO I/O
DAO / ORM...
SEPARE REPRESENTAÇÕES
String description = “Blah”
String date = “2010-02-26T19:35:24Z”
int step = 2
String description = “...
CONECTANDO CAMADAS
Estratégia Vantagens Desvantagens
Síncrono Método mais simples
Casos de uso não podem executar em
paral...
COMO TESTAR?
UNIT TESTS
(Mocked Contract)
FUNCTIONAL UI TESTS
INTEGRATION TESTS
USECASE
EXTERNAL WORLD ADAPTER
PRESENTER
VIEW CONTRACT
...
EVITE O SANDUÍCHE
UNEEDED ENTITY
UNEEDED USECASE
UNEEDED DOMAIN SERVICE
PRESENTER
• Sintoma da radicalidade de querer tudo...
ORGANIZE POR CONTEXTO
typical-packaging
├── activies
├── adapters
├── fragments
├── networking
├── ...
├── services
├── st...
ORGANIZAÇÃO FUNCIONAL
• Intenção explícita
• Localidade espacial
• Fácil Navegação
• Fácil identificar onde estão
dependênc...
CONCLUINDO
DIFICULDADES TÍPICAS
• “É preciso escrever muito código para ter algo realmente funcionando”
• Flerte constante com overen...
CONSIDERAÇÕES FINAIS
• Clean Architecture tem a ver com idéias de organizar as coisas e não
com fórmulas prontas
• Defina s...
UBIRATAN
SOARES
Computer Scientist by ICMC/USP
Software Engineer @ luizalabs
Google Developer Expert for Android
Teacher, ...
https://speakerdeck.com/ubiratansoares/escaping-from-the-framework
OBRIGADO
@ubiratanfsoares
ubiratansoares.github.io
https://br.linkedin.com/in/ubiratanfsoares
InterCon 2016 - Refactor direto e reto: migração de uma arquitetura 100% acoplada a um framework para uma arquitetura limpa
InterCon 2016 - Refactor direto e reto: migração de uma arquitetura 100% acoplada a um framework para uma arquitetura limpa
InterCon 2016 - Refactor direto e reto: migração de uma arquitetura 100% acoplada a um framework para uma arquitetura limpa
InterCon 2016 - Refactor direto e reto: migração de uma arquitetura 100% acoplada a um framework para uma arquitetura limpa
Upcoming SlideShare
Loading in …5
×

InterCon 2016 - Refactor direto e reto: migração de uma arquitetura 100% acoplada a um framework para uma arquitetura limpa

57 views

Published on

Ubiratan Soares, Software Engineer do Luiza Labs fala sobre Refactor direto e reto: migração de uma arquitetura 100% acoplada a um framework para uma arquitetura limpa no InterCon 2016.
Saiba mais em http://intercon2016.imasters.com.br/

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
57
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

InterCon 2016 - Refactor direto e reto: migração de uma arquitetura 100% acoplada a um framework para uma arquitetura limpa

  1. 1. ESCAPING FROM THE FRAMEWORK guided by Clean Archictecture Ubiratan Soares Outubro/2016
  2. 2. ERA UMA VEZ UM DESENVOLVEDOR ...
  3. 3. UM LUGAR COMUM • Documentações oficiais enviesam acoplamento • Senso comum direciona para arquiteturas orientadas a dados • Acoplamento dificulta testabilidade • Uso comum de GOD models, Fat Controllers, Views Inteligentes, Singletons e outros
  4. 4. 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)
  5. 5. App (Visão Romântica)
  6. 6. CONTROLLER CONTROLLER CONTROLLER CONTROLLER CONTROLLER CONTROLLER CONTROLLER CONTROLLER CONTROLLER CONTROLLER CONTROLLER CONTROLLER App (Visão Real) SINGLETON
  7. 7. WTF ?????
  8. 8. 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?
  9. 9. 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
  10. 10. COMO ESCAPAR DO FRAMEWORK ?
  11. 11. ARQUITETURA DE SOFTWARE • Uma maneira de organizar as coisas • 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
  12. 12. DATA-CENTRIC ARCHITECTURE UI BUSINESS LOGIC (MODEL + CONTROL) DATABASE NETWORKING ETC
  13. 13. UI Networking Entities Usecases Presenters Gateways DB Drivers Device Adapters Interactors DOMAIN CENTRIC (aka Clean) Data Access (External World REST, DB, etc) UI Bussiness Logic DATA CENTRIC
  14. 14. https://vimeo.com/43612849
  15. 15. 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 são essenciais Motivações Distinção entre essencial e detalhes
  16. 16. 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)
  17. 17. DOMAIN-CENTRIC ARCHITECTURE PRESENTATION LAYER DOMAIN LAYER DATA LAYER DB REST ETC UI . . .
  18. 18. 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
  19. 19. USECASE REST GATEWAY PRESENTER VIEW CONTRACT PLATAFORM CONTROLLER DEFINIR FRONTEIRAS SOURCE CONTRACT ENTITY APPLICATION CORE Associação Dependência
  20. 20. 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.execute( ) • PerformPurchase.execute(Review) • etc • Casos de uso fazem muito sentido quando existem oportunidades explícitas de reúso
  21. 21. 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
  22. 22. 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
  23. 23. 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
  24. 24. 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
  25. 25. COMO TESTAR?
  26. 26. 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)
  27. 27. EVITE O SANDUÍCHE UNEEDED ENTITY UNEEDED USECASE UNEEDED DOMAIN SERVICE PRESENTER • Sintoma da radicalidade de querer tudo SOLID • 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
  28. 28. 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
  29. 29. 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
  30. 30. CONCLUINDO
  31. 31. DIFICULDADES TÍPICAS • “É preciso escrever muito código para ter algo realmente funcionando” • Flerte constante com overengineering • Decisões de quantas e quais camadas adotar e quais são as apropriadas dependem de contexto, dentro da própria aplicação • Projetos em andamento não nascem nessa estrutura e precisam ser migrados; 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
  32. 32. 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)
  33. 33. UBIRATAN SOARES Computer Scientist by ICMC/USP Software Engineer @ luizalabs Google Developer Expert for Android Teacher, speaker, etc, etc
  34. 34. https://speakerdeck.com/ubiratansoares/escaping-from-the-framework
  35. 35. OBRIGADO @ubiratanfsoares ubiratansoares.github.io https://br.linkedin.com/in/ubiratanfsoares

×