Evoluindo Ecossistemas com Consumer Driven Contracts

Transcript

1. Evoluindo Ecossistemas com Contratos 1

2. aos envolvidos... 2

3. Marcos Matos Thiago Colucci doravante denonimados de OS PALESTRANTES 3

4. desenvolvedores na ThoughtWorks doravante denonimada de A EMPRESA 4

5. Imaginem manter uma aplicação de 1 000 000 linhas de

   código 5

6. Ninguém mais faz isso hoje em dia, certo? (eu espero

   que seja certo) 6

7. nós criamos REST SOAP RPCs 7 (blarg!) (meus olhooooos)

8. Técnicas para separar um sistema em vários componentes 8

9. doravante denominados Micro Serviços 9

10. Micro Serviço Uma base de código pequena com uma funcionalidade

    bem definida (the Unix Way) 10

11. nós movemos de... 11

12. 12 grandes aplicações monolíticas

13. para 13

14. 14 diversos micro serviços

15. Que podem evoluir independentemente 15

16. Assim acabamos com a complexidade em nossos sistemas! 16

17. None

18. Na verdade o que fazemos é mover esta complexidade 18

19. Princípio da Conservação de Energia A quantidade total de complexidade

    de um sistema computacional permanece constante 19 Complexidade Vários caras espertos

20. Uma arquitetura de micro serviços levanta diversas perguntas 20

21. como por exemplo o paradoxo dos contratos 21

22. Contrato Promessa de como se dá a interação com um

    serviço. (Uma API + Boa fé) 22

23. 23 /usuarios/:email um ENDPOINT { nome: “marcos”, idade: 27 }

    uma RESPOSTA exemplo de um contrato

24. 24 um serviço expõe sua funcionalidade

25. 25 vários clientes começam a depender do contrato

26. 26 não se sabe como alterações afetam os clientes

27. Serviços desacoplados se tornam acoplados novamente! 27

28. pior! este acoplamento é totalmente Oculto! 28

29. como lidar com isso? 29

30. Exibição #1 A abordagem do Twitter 30

31. None

32. Exibição #2 A abordagem do Facebook 32

33. None

34. Bem, digamos que voce não trabalha para estas empresas 34

35. momento True Story 35

36. Exibição #3 Revele o oculto 36

37. Contratos Executáveis! 37

38. 38 um CLIENTE precisa de uma funcionalidade

39. 39 o cliente então escreve uma especificação executável desta funcionalidade

40. 40 o cliente então compartilha a spec com o provedor

    o CLIENTE o PROVEDOR a SPEC

41. 41 Ambos discutem a spec até que haja um acordo

    o CLIENTE o PROVEDOR o CONTRATO

42. O cliente escreve seus testes utilizando o contrato o CLIENTE

    o PROVEDOR Enquanto o provedor implementa a funcionalidade

43. 43 cliente escreve testes em isolamento o CLIENTE o PROVEDOR

    o Contrato TESTES de aceitação

44. 44 contratos são testados contra o provedor o CLIENTE o

    PROVEDOR o Contrato TESTES de validação

45. o PROVEDOR os CLIENTES os CONTRATOS

46. contratos são uma ferramenta de comunicação 46

47. são executáveis e devem ser compartilhados 47

48. garantindo seus contratos, um serviço pode evoluir livremente 48

49. Sim, isto é um pattern =P Consumer Driven Contracts 49

    http://martinfowler.com/articles/consumerDrivenContracts.html

50. e também temos uma gem =D 50 https://github.com/thoughtworks/contracts

51. demo time! 51

52. perguntas? 52

53. obrigado! 53