Práticas de desenvolvimento de software para um arquitetura evolutiva.

1. ARQUITETURA
EVOLUTIVA
Construindo uma
Arquitetura de Forma Ágil

2. SOBRE MIM
Consultora de
Desenvolvimento de
Software
EDLAINE ZAMORA
Onde eu trabalho: ThoughtWorks
O que já fui/fiz: Líder Técnica, Desenvolvedora,
Análise de Qualidade, Análise de Negócio…
O que estou fazendo agora: Treinadora na
ThoughtWorks University
2

3. ESSA APRESENTAÇÃO NÃO VAI
● Ensinar microserviços
● Falar sobre MVC
● Ajudar a escolher um framework JavaScript
● Ensinar uma arquitetura que resolve todos os problemas
3

4. “Arquitetura de Software é
sobre coisas importantes.
(seja lá o que forem).”
—RALPH JOHNSON
4

5. “O trabalho de pessoas
arquitetas de software é
entender e balancear todas
essas coisas importantes (o
que quer que elas sejam)”
—NEAL FORD, REBECCA PARSONS E PATRICK KUA
5

6. ARQUITETURA
DE SOFTWARE
O ESCOPO DE ARQUITETURA
DE SOFTWARE ABRANGE
REQUISITOS + "ILITIES" +
DIMENSÕES.
6

7. OS "ILITIES" DA ARQUITETURA
7

8. ALTO CUSTO
DE
MUDANÇA
Escolha bem o seu processo de
desenvolvimento de software
com foco em diminuir o custo
de mudança.
8

9. ALTO CUSTO DE
MUDANÇA
+
TUDO
MUDANDO O
TEMPO TODO...
9

10. A MUDANÇA É CONSTANTE
1999 2000 2004 2007 2010 2013 2014
SEM CONTAR AS
BIBLIOTECAS E
FRAMEWORKS JAVASCRIPT
198* 2017 ...
2001
MANIFESTO ÁGIL
10

11. AFINAL
O QUE É
ARQUITETURA
EVOLUTIVA?
11

12. —MARTIN FOWLER
“O coração da arquitetura evolutiva é fazer
pequenas mudanças e coletar feedbacks que
permitam que todos aprendam como o
sistema está se desenvolvendo.
A entrega contínua tem sido um fator crucial
para isso."
12

13. —EDLAINE ZAMORA
“A arquitetura evolutiva é construída com a
cultura do ágil, possui evolução constante
através de colaboração e permite mudanças
de negócio e do ecossistema com o menor
custo possível."
13

14. —NEAL FORD, REBECCA PARSONS E PATRICK KUA
“A arquitetura evolutiva suporta
mudanças guiadas e incrementais
através de múltiplas dimensões."
14

15. LEI DE CONWAY
"Organizações que projetam
sistemas ... são obrigadas a
produzir projetos que são cópias
das estruturas de comunicação
dessas organizações."
—MELVIN CONWAY
15

16. MANOBRA DE
CONWAY INVERSA
"Recomenda a evolução de
sua equipe e estrutura
organizacional para atingir a
arquitetura desejada"
16

17. CARACTERÍSTICAS PRINCIPAIS DA
ARQUITETURA EVOLUTIVA
01
Fazer mudanças
incrementais ao
longo do tempo
Tomar decisões no
último momento
responsável
02
Arquitetar para a
evolução03
Desenvolver para a
evolução04
Arquitetar para
testabilidade05
17

18. POR ONDE
COMEÇAR?
18

19. Classificar o que é mais
importante de acordo
com as necessidades de
negócio do produto.
DEFINA AS
CARACTERÍSTICAS
ARQUITETURAIS MAIS
IMPORTANTES PARA O
NEGÓCIO
19

20. Qual o tipo de arquitetura,
qual a arquitetura de
dados, quais tecnologias e
como isso tudo vai se
comunicar.
DEFINA O
DESENHO INICIAL
DE SUA
ARQUITETURA
20

21. CRIE FITNESS
FUNCTIONS
PARA ELAS
Fitness Functions vão dirigir
decisões arquiteturais, guiando
a arquitetura enquanto
permite alterações para
suportar mudanças de negócio
e de tecnologias.
21

22. Técnicas de
desenvolvimento de
software que podem
ajudar na construção e
manutenção de uma
arquitetura evolutiva
22

23. CI/CD: Integração,
Deploy e Entrega
Contínua
01
Automatizar a integração do
código, execução de testes,
construção e deploy da aplicação
facilitam a evolução constante da
arquitetura através de feedbacks
rápidos.
23

24. Feature Toggle/
Feature Flag02
Ter a habilidade de habilitar ou
desabilitar uma funcionalidade na
aplicação auxilia na integração e
deploy contínuos e testes em
diferentes ambientes.
24

25. Migração de
Banco de Dados03
Utilizar mecanismos que
controlam as mudanças no banco
de dados torna a dimensão de
dados também evolutiva.
25

26. Teste de Contrato
04 Usar o teste de contrato para testar
a interface da integração entre os
diferentes componentes da
arquitetura ajuda na documentação
de suposições que um serviço faz
com relação ao outro e a manter a
integração funcionando.
26

27. Coreografia
05 Usar coreografia pode
flexibilizar a comunicação entre
os diferentes serviços e
fornecer mais autonomia sobre
o fluxo principal de negócio.
27

28. Monitoramento
Mensurar o impacto que as
mudanças contínuas têm no
negócio e na arquitetura ajuda a
evoluir com mais segurança e
para o caminho certo.
06
28

29. UM CASO
REAL
Erros e Acertos na
implementação de
uma arquitetura.
29

30. CONTEXTO DO PRODUTO
Principais objetivos de negócio
● Ser uma plataforma de venda independente do tipo
do produto ou serviço a ser ofertado
● Time to market - possibilitar a inserção do produto
ou serviço no mercado de forma rápida
● Escalabilidade de desenvolvimento - prover
mecanismos para que os times de produtos ou
serviços sejam autônomos com relação ao time da
plataforma
30

31. ABORDAGEM
Definição de uma arquitetura de
serviços, síncrona e separada por
3 domínios: produtos,
pagamentos e pedidos/ofertas
em forma de serviços.
31

32. PRINCIPAIS ERROS
Falta de priorização das
características
arquiteturais
Tentativa de definição da
arquitetura completa no
início do projeto
Não exploração das
possibilidades
arquiteturais
Aplicação da Lei de
Conway
32

33. CONSEQUENCIAS
O que descobrimos com a arquitetura construída:
● Não suportava especificidades dos produtos
● Time to market era alto por dependência entre times
● Não escalava o desenvolvimento por dependência de times
específicos
33

34. COMO FIZEMOS
PARA
CONSERTAR AS
COISAS?
34

35. FLUXO DO
TRABALHO
35

36. RESULTADO
Após a mudança da arquitetura
● A plataforma conseguiu aceitar diferentes tipos de produtos e
serviços porque não era acoplada a eles
● Time to market ficou razoável porque havia pouca dependência
entre times (mas ainda havia complexidade de integração)
● Passou a escalar o desenvolvimento devido a independência entre
times específicos
36

37. EXEMPLOS DE FITNESS FUNCTIONS
Teste a Performance de sua Aplicação
37

38. EXEMPLOS DE FITNESS FUNCTIONS
Teste os Padrões de Codificação de sua Aplicação
38

39. EXEMPLOS DE FITNESS FUNCTIONS
Teste a Resiliência de sua Aplicação
39

40. EXEMPLOS DE FITNESS FUNCTIONS
Teste a Resiliência de sua Aplicação
40

41. EXEMPLOS DE FITNESS FUNCTIONS
Teste a Resiliência de sua Aplicação
41

42. ARQUITETURA EVOLUTIVA
EM RESUMO
Identifique suas
características
arquiteturais mais
importantes.
Identifique fitness function
para elas e automatize o
que for possível e viável.
Adie suas decisões o
máximo que puder (com
responsabilidade)
Crie e mantenha um
ecossistema de testes para
manter a evolução segura.
42

43. REPRESENTATIVIDADE IMPORTA
Camilla Crispim Roberta Arcoverde Paula Santana Luiza Guerra Juliana Helena Thalita Pinheiro Gabriela Mattos Beda
Érika Silva Thais Freitas
(Manola)
Beatriz Herculano Nayara Souza Yasminn Vaz Dani Marinho
Daniela Araujo Lais Gomes Manu Schiavon Angie Jones Zhamak Dehghani
Rebecca Parsons
43
Ana Ludmila

44. OBRIGADA
@edlainezamora
edlainezamora
44