Marcel Gonçalves dos Santos
@marcelgsantos
arquitetura de software
O bê-a-bá da
Slide 2
Slide 2 text
pensandonaweb.com.br
desenvolvedor web full-stack
Marcel Gonçalves dos Santos
@marcelgsantos
Slide 3
Slide 3 text
@phpsp
phpsp.org.br
Slide 4
Slide 4 text
Interaja nas mídias sociais!
- fale sobre o evento, palestrantes e conteúdo
- tire fotos do evento e publique
- interaja com outros participantes do evento
- tire dúvidas ou dê feedbacks para os palestrantes
Slide 5
Slide 5 text
O que é
arquitetura de software?
Slide 6
Slide 6 text
a arquitetura de software de um sistema
consiste na de
fi
nição dos componentes de
software, suas propriedades externas e seus
relacionamentos com outros softwares
Slide 7
Slide 7 text
"A g
oo
d
ar
chitect
ur
e is imp
or
tant, oth
er
wise it
bec
om
es sl
ow er
and m
or
e
ex
pensive to add
new capabilities in the fut
ur
e."
― M
ar
tin F
ow
l
e
Slide 8
Slide 8 text
"...g
oo
d
ar
chitect
ur
e is s
om
ething that
supp
or
ts its
ow
n ev
ol
uti
o
, and is deeply
int
er
twined with pro
gr
amming."
― M
ar
tin F
ow
l
e
Slide 9
Slide 9 text
uma boa arquitetura:
1. torna evidente a organização do código
2. permite a evolução do código com pouca fricção
3. entrega valor de negócio de forma consistente
4. garante a qualidade e con
fi
abilidade do software
Slide 10
Slide 10 text
a arquitetura de software permite lidar com
a complexidade de software de forma mais
controlada
Slide 11
Slide 11 text
Complexidade acidental
e complexidade essencial
Slide 12
Slide 12 text
o domínio é o coração do software e onde
estão as regras de negócio
Slide 13
Slide 13 text
"The he
ar
t of softw
ar
e is its ability to s
ol
ve
d
om
ain-related problems f
or
its us
er
."
― Eric Evans, D
om
ain-Driven Design
Slide 14
Slide 14 text
o domínio possui uma complexidade
intrínseca, isto é, a complexidade do
problema a ser resolvido
Slide 15
Slide 15 text
a complexidade acidental é aquela que é
decorrente da solução adotada
Slide 16
Slide 16 text
exemplo 01
escolher entre utilizar monolitos ou
microsserviços, framework A ou B, banco de
dados relacionais ou não-relacionais são
exemplos de complexidades acidentais
Slide 17
Slide 17 text
a complexidade essencial é aquela que é
inerente ao problema a ser resolvido
Slide 18
Slide 18 text
exemplo 02
a coordenação de motoristas de aplicativos,
isto é, identi
fi
car os motoristas disponíveis
nas imediações da solicitação de uma
chamada é um exemplo de complexidade
essencial pois faz parte do problema
Slide 19
Slide 19 text
a complexidade essencial é aquela que
não pode ser evitada e está relacionada
a complexidade do domínio
Slide 20
Slide 20 text
a arquitetura de software in
fl
uencia na
complexidade acidental do código de forma
positiva ou negativa conforme o contexto
Slide 21
Slide 21 text
"It's the duty of the
ar
chitect to s
ol
ve the
problems inh
er
ent in essential c
om
pl
ex
ity
with
ou
t in
tr
oducing accidental c
om
pl
ex
ity."
― Neil F
or
d
Slide 22
Slide 22 text
Diferença entre arquitetura
e design de software
Slide 23
Slide 23 text
existe uma linha tênue que que delimita a
diferença entre arquitetura e design de
software e isso causa muita confusão
Slide 24
Slide 24 text
a arquitetura de software pode ser vista
como uma organização de alto nível dos
componentes de um software, isto é, sobre
aspectos mais genéricos e de negócio
Slide 25
Slide 25 text
o design de software pode ser visto como
uma organização de baixo nível dos
componentes de um software, isto é, no nível
do código como módulos, classes e funções
Slide 26
Slide 26 text
"Atividades relaci
on
adas a
ar
quitet
ur
a de
softw
ar
e são sempre de design. En
tr
etanto,
nem todas atividades de design são sobre
ar
quitet
ur
a."
― Elem
ar
Juni
o
Slide 27
Slide 27 text
O que faz um(a)
arquiteto(a) de software?
Slide 28
Slide 28 text
a pessoa arquiteta de software tem como
objetivo projetar aplicações utilizando
conceitos de arquitetura e boas práticas de
desenvolvimento
Slide 29
Slide 29 text
deve-se levar em consideração a estratégia
da empresa na tomada de decisão técnica
Slide 30
Slide 30 text
essa pessoa pode atuar como um guia
técnico de uma equipe que irá conduzir o
projeto, arquitetura e implementação
Slide 31
Slide 31 text
o papel da pessoa arquiteta de software
pode ser exercido de forma transversal
entre as várias pessoas da equipe
Slide 32
Slide 32 text
ajuda a evitar a
fi
gura do Ivory Tower
Architect ou arquiteto na torre de mar
fi
m
Slide 33
Slide 33 text
No content
Slide 34
Slide 34 text
No content
Slide 35
Slide 35 text
O que são estilos
e padrões arquiteturais?
Slide 36
Slide 36 text
um estilo arquitetural de
fi
ne como o código
é organizado sob uma perspectiva de alto
nível, isto é, como os módulos de alto nível
de uma aplicação estão relacionados
Slide 37
Slide 37 text
são exemplos de estilos arquiteturais:
- arquitetura monolítica
- arquitetura baseada em componentes
- arquitetura cliente-servidor
- arquitetura em camadas
- pipes and
fi
lters
- arquitetura orientada a eventos
Slide 38
Slide 38 text
são exemplos de estilos arquiteturais:
- arquitetura orientada a serviços
- arquitetura publish-subscribe
- arquitetura de plugins
- arquitetura de microsserviços
- arquitetura REST
Slide 39
Slide 39 text
um padrão arquitetural é uma solução
reutilizável para problemas comuns na
arquitetura de software dentro de um
contexto especí
fi
co
Slide 40
Slide 40 text
um padrão arquitetural é uma forma de
implementar um estilo arquitetural
Slide 41
Slide 41 text
são exemplos de padrões arquiteturais:
- model-view-controller
- onion architecture
- arquitetura hexagonal ou ports and adapters
- arquitetura limpa
- CQRS
- event sourcing
Slide 42
Slide 42 text
Arquitetura spaghetti
ou big ball of mud
Slide 43
Slide 43 text
uma "big ball of mud" ou grande bola de
lama é um código com uma arquitetura mal
de
fi
nida…
Slide 44
Slide 44 text
…e que correções e pequenas evoluções se
tornam um grande desa
fi
o pela di
fi
culdade
de compreender o código
Slide 45
Slide 45 text
No content
Slide 46
Slide 46 text
"A big ball of mud is haphaz
ar
dly
s
tr
uct
ur
ed, sprawling, sl
op
py, duct-tape
and bailing w
ir
e, spaghe
tt
i code jungle.”
― Brian F
oo
te and Joseph Yod
er
, 1999
Slide 47
Slide 47 text
"Uma
gr
ande b
ol
a de lama é uma selva de
código espaguete, aleat
or
iamente es
tr
ut
ur
ado,
espalhado, desle
ix
ado e cheio de fita adesiva."
― Brian F
oo
te and Joseph Yod
er
, 1999
Slide 48
Slide 48 text
"Questi
on
s ab
ou
t wheth
er
design is necess
ar
y
or
aff
or
dable
ar
e quite beside the p
oi
nt:
design is inevitable. The alt
er
native to g
oo
d
design is bad design, not no design at all."
― D
ou
glas M
ar
tin
Slide 49
Slide 49 text
Arquitetura
model-view-controller
Slide 50
Slide 50 text
o MVC ou Model-View-Controller
fi
cou
conhecida com a popularização de
frameworks web
Slide 51
Slide 51 text
ele permite a separação da aplicação nas
três camadas seguintes: controller, model e
view
Slide 52
Slide 52 text
controller
recebe a requisição HTTP e orquestra o
acesso a model e a renderização da view
Slide 53
Slide 53 text
model
camada responsável pelas regras de negócio
e acesso a dados
Slide 54
Slide 54 text
view
camada responsável pela representação
visual que será enviada ao cliente
Slide 55
Slide 55 text
No content
Slide 56
Slide 56 text
é um padrão de fácil compreensão e
amplamente conhecido entre
desenvolvedores(as)
Slide 57
Slide 57 text
ele costuma ser a porta de entrada para a
compreensão e utilização de padrões de
arquitetura no desenvolvimento de software
Slide 58
Slide 58 text
contudo, ele se mostra insu
fi
ciente para a
organização de código em uma parte
considerável de aplicações modernas
Slide 59
Slide 59 text
ele pode levar para o surgimento do anti-
pattern fat controllers no código com
controllers com regras de negócio e cada
vez maiores
Slide 60
Slide 60 text
o código
fi
ca altamente acoplado ao
mecanismo de entrega
Slide 61
Slide 61 text
Arquitetura
em camadas
Slide 62
Slide 62 text
a arquitetura em camadas é utilizada para
organizar a aplicação e permite separá-la em
camadas com responsabilidades especí
fi
cas
Slide 63
Slide 63 text
cada camada depende somente das
camadas abaixo (direta ou indiretamente) e
não tem conhecimento das camadas acima
Slide 64
Slide 64 text
No content
Slide 65
Slide 65 text
interface de usuário
responsável por exibir informações e
interpretar comandos do usuário
Slide 66
Slide 66 text
aplicação
responsável por conectar a camada de
interface de usuário com as outras camadas
Slide 67
Slide 67 text
domínio
responsável por conter os conceitos e regras
de negócio relacionados ao domínio e é o
principal foco do domain-driven design
Slide 68
Slide 68 text
infraestrutura
responsável por fornecer os recursos
técnicos que dão suporte às outras camadas
como persistência de dados e I/O
Slide 69
Slide 69 text
"Is
ol
ating the d
om
ain implementati
on
is a
pr
er
equisite f
or
d
om
ain-driven design."
― Eric Evans
Slide 70
Slide 70 text
Arquitetura hexagonal
ou ports and adapters
Slide 71
Slide 71 text
a arquitetura hexagonal ou arquitetura
ports and adapters foi criada por Alistair
Cockburn e descrita no seu blog em 2005
Slide 72
Slide 72 text
"All
ow
an applicati
o
to equally be driven by
us
er
s, pro
gr
ams, aut
om
ated test
or
batch s
cr
ipts,
and to be devel
op
ed and tested in is
ol
ati
o from
its
eventual run-time devices and databases."
― Alista
ir
Cockb
ur
n
Slide 73
Slide 73 text
a ideia é pensar na aplicação como um
artefato central de um sistema em que toda
entrada e saída…
Slide 74
Slide 74 text
…aconteça através de uma porta que isola a
aplicação de ferramentas externas e
mecanismos de entrega
Slide 75
Slide 75 text
a aplicação não deve saber (1) com quem
ela se comunica e (2) nem quem se
comunica com ela
Slide 76
Slide 76 text
No content
Slide 77
Slide 77 text
uma porta é um ponto de entrada ou saída da
aplicação e pode ser representada por uma
interface na sua linguagem de programação
Slide 78
Slide 78 text
um adaptador é a implementação da
comunicação do mundo externo e a
aplicação e vice-versa
Slide 79
Slide 79 text
uma porta é uma intenção de comunicação
e um adaptador é uma implementação da
comunicação
Slide 80
Slide 80 text
costuma-se implementar a arquitetura
hexagonal com três camadas:
infraestrutura, aplicação e domínio
Slide 81
Slide 81 text
a regra de dependência das camadas é
sempre de fora para dentro, isto é, as
camadas internas não tem conhecimento do
mundo externo
Slide 82
Slide 82 text
No content
Slide 83
Slide 83 text
pode-se alcançar esse comportamento
através do princípio da inversão de
dependência
Slide 84
Slide 84 text
a utilização da arquitetura ports and
adapters torna a aplicação isolada de
detalhes de implementação e facilmente
testável
Slide 85
Slide 85 text
Arquitetura limpa
ou clean architecture
Slide 86
Slide 86 text
a arquitetura limpa foi criada por Robert C.
Martin e possui muitas semelhanças com
ports and adapters e onion architecture
Slide 87
Slide 87 text
a principal semelhança é a separação de
responsabilidades que é alcançada através
da separação de camadas
Slide 88
Slide 88 text
No content
Slide 89
Slide 89 text
a regra de dependência é outro elemento
conceitual importante na arquitetura limpa
Slide 90
Slide 90 text
ao criar um software separado em camadas
e que obedece a regra de dependência ele
se torna facilmente testável e
independente de elementos externos
Slide 91
Slide 91 text
Conclusão
Slide 92
Slide 92 text
a arquitetura de software é uma disciplina
importante no desenvolvimento de software
que permite criar um código aderente ao
negócio e que evolua de forma consistente
Slide 93
Slide 93 text
existem inúmeros conceitos relacionados a
design e arquitetura de software que são
fundamentais para a construção de um
software com uma boa arquitetura
Slide 94
Slide 94 text
desde princípios básicos como coesão e
acoplamento, passando por conceitos como
separação de responsabilidade e tocando
em outros princípios como o SOLID
Slide 95
Slide 95 text
essa é só a porta de entrada para o
fantástico mundo da arquitetura de software