Livro FullCycle-0.6

Full Cycle
Wesley Willians
Esse livro está à venda em http://leanpub.com/fullcycle
Essa versão foi publicada em 2023-01-31
Esse é um livro Leanpub. A Leanpub dá poderes aos autores e editores a partir

do processo de Publicação Lean. Publicação Lean é a ação de publicar um
ebook em desenvolvimento com ferramentas leves e muitas iterações para
conseguir feedbacks dos leitores, pivotar até que você tenha o livro ideal e
então conseguir tração.
© 2021 - 2023 Full Cycle Ltda

Conteúdo
Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
A mudança de perspectiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Full Cycle Developers @Netflix . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Devs com muitas responsabilidades . . . . . . . . . . . . . . . . . . . . . . . 4
Times de plataforma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Você é Full Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Introdução à Arquitetura de Software . . . . . . . . . . . . . . . . . . . . . . . . 7

Sustentabilidade no dia zero . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Modalidades arquiteturais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
O que é arquitetura de software . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Pilares da arquitetura de software . . . . . . . . . . . . . . . . . . . . . . . . 29
Requisitos arquiteturais na prática . . . . . . . . . . . . . . . . . . . . . . . . 35
Características Arquiteturais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Características Operacionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Características Estruturais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Características Cross-Cutting . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Perspectivas para arquitetar software de qualidade . . . . . . . . . . . . 60
CONTEÚDO
Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Escalando software: vertical vs horizontal . . . . . . . . . . . . . . . . . . . 80
Escalando software: descentralização . . . . . . . . . . . . . . . . . . . . . . 82
Introdução à resiliência . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Service mesh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Sistemas Monolíticos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

Sistemas “tradicionais” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Restrições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Monolitos não são ruins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Deploy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Necessidade de escala . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Débitos técnicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Domain Driven Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Ponto de partida no DDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
As complexidades de um software . . . . . . . . . . . . . . . . . . . . . . . . 130
Como o DDD pode te ajudar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Resumindo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Espaço do problema vs espaço da solução . . . . . . . . . . . . . . . . . . . 140
Contexto delimitado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Arquitetura Hexagonal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

Introdução à Arquitetura Hexagonal . . . . . . . . . . . . . . . . . . . . . . 157
CONTEÚDO
A importância da Arquitetura de Software . . . . . . . . . . . . . . . . . . 159

Ciclo de vida de um projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Introdução
A mudança de perspectiva
Foi em 2015 quando comecei ouvir com frequência o termo microsserviços. A

cada palestra e apresentação de cases de grandes empresas, ficava mais evidente
de que essa tendência iria perdurar por algum tempo.
Grandes empresas e unicórnios precisavam crescer rapidamente, gerar mais

valor a cada dia, contratar mais pessoal e ter mais independência entre seus
projetos. Por outro lado, quanto mais ouvia falar sobre microsserviços, também
mais era evidente que utilizar tal arquitetura não era trivial. Muitas peças ainda
precisavam se encaixar para que esse modelo pudesse se tornar algo mais natural
nas organizações.
A complexidade de arquitetar, desenvolver, testar, realizar o deploy e monitorar

uma única aplicação estava sendo multiplicada pelo número de microsserviços
que cada empresa possuia. Apesar de muitos projetos serem pequenos, ainda
assim, todos precisavam passar por essas etapas.
Com o número de sistemas crescendo exponencialmente, a área de operações

dessas empresas também começou a colapsar. Profissionais que estavam acos-
Introdução 2
tumados a receber demandas de devs para realizarem quatro deploys diários,

tiveram suas rotinas alteradas para realizar quarenta ou quatrocentos.
O número de aplicações a serem monitoradas também foi se multiplicando, e

conflitos entre pessoas desenvolvedoras e sysadmins se intensificaram. Estava
muito claro que já estávamos em uma nova era. Uma era que não tinha mais
volta.
Full Cycle Developers @Netflix
Em 17 de maio de 2018, alguns profissionais da Netflix que já possuíam anos

de casa, também compartilharam suas dores e tentativas que vinham realizando
desde 2012.
Naquela época, não muito diferente de outras organizações, eles possuíam papéis
extremamente bem definidos para o ciclo de desenvolvimento de um software.
Imagem retirada do Tech Blog da Netflix.
A Netflix deixou de ser apenas um arquivo “war” e também foi dividida em

microsserviços.
Introdução 3
Depois de muitos erros e acertos, perceberam que um dos principais pontos que
sem dúvidas mudaria o jogo, seria transferir totalmente a responsabilidade de
cada projeto para seus times de desenvolvimento, ou seja: agora os desenvolve-
dores fariam parte de todo o ciclo de desenvolvimento de suas aplicações. Da
arquitetura ao deploy e monitoramento.
O grande lema se tornou: “Operate what you build”, ou opere o que você mesmo
constrói. O raciocínio foi remover intermediários de todo processo e fazer com
que a equipe de dev fique 100% responsável por seu microsserviço sendo capaz
de trabalhar com feedbacks curtos de todo processo e aprender rapidamente com
isso.
Introdução 4
Imagem retirada do Tech Blog da Netflix.
Devs com muitas responsabilidades
Se você é uma pessoa desenvolvedora, com certeza já sabe o número imenso

de responsabilidades que possui no dia a dia para entregar software com alta
qualidade.
A grande questão é: colocar mais responsabilidades nas “costas” da pessoa

Introdução 5
desenvolvedora é realmente a solução?
Foi exatamente essa pergunta que fiz para mim mesmo assim que estava na
metade do artigo. Porém, ao continuar com a leitura percebi que os autores
deram uma solução para minimizar esse fardo e ao mesmo empoderar devs
cansados e estressados com tantos conflitos que resultavam em idas e vindas
junto a área de operações para solucionar problemas em produção e para colocar
suas aplicações no ar.
A solução criada estava na utilização de ferramentas desenvolvidas especifi-

camente para que a pessoa desenvolvedora tivesse total autonomia para que
realizar um deploy e entender em tempo real o comportamento de uma aplicação,
de forma simples, rápida e que fundamentalmente fizesse parte do fluxo natural
de trabalho.
Times de plataforma
Se você atualmente trabalha em alguma empresa que minimamente possui

processos de desenvolvimento bem definidos, bem como possui o mínimo de
uma cultura DevOps implementada, acredito que tudo que você leu até o
momento representa a sua realidade de trabalho atual.
Grande parte das empresas já possui times de plataforma, que têm o objetivo
de dar suporte e autonomia para as pessoas desenvolvedoras no dia a dia. Esses
times criam ferramentas, padronizam pipelines exatamente para que o processo
Introdução 6
de desenvolvimento no dia a dia seja fluido e produtivo, sem tirar o foco na

entrega de valor pelos devs.
Você é Full Cycle
Se você participa do fluxo completo de uma aplicação, você é um Full Cycle

Developer, todavia, como qualquer profissional de tecnologia, a evolução precisa
ser constante; e esse é o objetivo desse livro: abranger os principais aspectos do
mundo Full Cycle, e te tornar capaz de desenvolver aplicações de grande porte
utilizando as tecnologias mais modernas do mercado onde quer que você esteja.
A partir de agora, vamos partir para uma jornada completa do Software Develop-
ment Life Cycle. Vamos partir do mundo da arquitetura de software até o deploy
e monitoramento de aplicações de grande porte.
Introdução à Arquitetura de
Software
Neste capítulo explicaremos o que é a arquitetura de software. Os conhecimentos
sobre esse tema podem nos auxiliar desde o processo de desenvolvimento de uma
solução até sua sustentabilidade.
Um dos pontos fundamentais que, sem dúvidas, diferencia um desenvolvedor,

é o quanto ele está preparado para desenvolver softwares sustentáveis, ou
seja, aquele software que consegue ao longo do tempo gerar valor para uma
organização. O software sustentável é flexível e permite grandes mudanças sem
muita necessidade de reescritas.
Assim, gostaria essencialmente de fazer três “provocações” que ajudarão você

entender a real essência da Arquitetura de Software:
1. Qual a fórmula para criarmos softwares sustentáveis?

2. O que realmente é Arquitetura de Software?
3. Qual a relação entre a sustentabilidade de um software e a sua arquitetura?
Introdução à Arquitetura de Software 8
Sustentabilidade no dia zero
Geralmente o termo sustentabilidade está relacionado à realização de atividades

que busquem a preservação do meio ambiente. Porém, quando usamos esse
termo para falar do desenvolvimento de um software, sua definição é um
pouco diferente. Dizer que um software é sustentável é o mesmo que dizer que
esse software foi arquitetado para evoluir dentro de uma organização. Ou seja,
continuar existindo pelo maior tempo possível.
De forma geral, desenvolver uma aplicação é extremamente caro e, por isso,

traz impactos diretamente na performance da empresa, principalmente na área
de investimentos dessa organização. Hoje em dia, sabemos que grande parte
das corporações que estão nascendo, e que inclusive estão revolucionando o
mundo todo, são empresas de tecnologia, logo, o desenvolvimento de sistemas
é uma parte core da companhia. A Lyft, a Uber e o iFood são alguns exemplos
de organizações em que grande parte do investimento para que elas possam
funcionar é relacionado às tecnologias.
Outro ponto importante que precisamos entender é que o software, de modo ge-
ral, busca resolver uma “dor” que a organização tem. Então, utilizando o exemplo
do iFood, por ser uma empresa de tecnologia voltada a entrega de alimentos, algo
que poderia ser feito por meio de uma ligação telefônica, essa precisou evoluir
para assim ter diferenciais que fizessem com que a empresa pudesse se manter
no mercado. Por exemplo, seu software tem mais escalabilidade para ele seja
viável no dia a dia e assim se diferenciar de pedidos por ligações telefônicas,

conseguindo atender a demanda do mercado.
O software pode ser considerado parte de uma empresa, ou seja, a medida que a
organização evoluiu esse software precisa evoluir também. Ele precisa se manter,
evoluindo, de forma que o custo dele seja muito menor do que o resultado que
ele está trazendo para a corporação. Desse modo, haverá um ponto de equilíbrio,
isto é, a solução conseguirá retornar seu investimento.
Quando as empresas se dão conta de que determinado software chegou em seu

limite de evolução, novos projetos de “modernização tecnológica” são criados
exatamente para dar conta do que o software “legado” não conseguiu. Com
certeza se você já está no mercado há alguns anos, você já ouviu algum caso
parecido com o citado acima. Agora, a pergunta que podemos nos fazer é: o
software parou de evoluir realmente por que a tecnologia evoluiu muito ou por
que a forma com que ele foi criado tornou sua evolução cada vez mais caótica?
Sem dúvidas a tecnologia evolui. Novas linguagens, frameworks, bibliotecas são

criadas todos os dias, porém, em muitos casos, a forma com que um software
é criado tem um peso infinitamente superior do que a tecnologia utilizada pelo
mesmo.
O software precisa nascer sustentável e continuar em produção pelo maior

tempo possível. Quanto mais tempo ele fica no ar, mais retorno ele gera para
a empresa e isso só é possível se sua base for bem feita. Só é possível se no
dia zero cada desenvolvedor, arquiteto, product owner, entre outros, de forma
intencional, pensarem em como fazer com que esse software fique no ar e
entregue valor por diversos anos.
Então, para que um software seja sustentável, ele precisa ser bem arquitetado,
assim poderá se manter mais tempo no ar e conseguir gerar mais retorno para
a organização. Ou seja, sem sustentabilidade no dia zero o software pode trazer
mais prejuízos do que valor e isso pode significar a razão da empresa continuar
ou não suas operações.
Modalidades arquiteturais
Entender sobre arquitetura de software é essencial para desenvolvedores que

almejam trabalhar em grandes projetos. Esse entendimento vai expandir sua
compreensão sobre o desenvolvimento de sistemas e, assim, aumentar as possi-
bilidades de trabalho em sua carreira como pessoa desenvolvedora.
É importante dizer que, dentro de uma organização, a arquitetura, de forma

geral, contribui para que seja gerado valor ao negócio. Nesse sentido, é extre-
mamente relevante para a corporação ter profissionais com experiência na área.
Podemos chamar esses profissionais de arquitetos. Existem diferentes tipos de
arquitetos, porém apresentaremos neste módulo quatro que são considerados
mais relevantes para área de desenvolvimento de sistemas.
No primeiro tópico, falaremos sobre o arquiteto tecnológico, depois sobre o

arquiteto corporativo, no terceiro tópico sobre o arquiteto de solução e, por

último, sobre o arquiteto de software.
Os profissionais que trabalham nessas modalidades são de grande relevância

para as organizações, pois além de terem um amplo conhecimento técnico em di-
versas áreas, suas decisões impactam diretamente no processo de planejamento
e desenvolvimento de soluções nas organizações como um todo. Lembrando
que, dependendo da empresa, essas funções podem sofrer algumas variações ou
muitas vezes serem inexistentes (a depender da necessidade).
Arquitetura tecnológica
Neste tópico falaremos um pouco sobre quem é e o que faz uma pessoa arquiteta
tecnológica. Daremos exemplos para que se perceba qual sua importância dentro
de um negócio.
Essa pessoa é basicamente alguém com especialidade em uma determinada tec-

nologia. Por possuir conhecimento elevado, conhece detalhes sobre a tecnologia
na qual é habilitada.
Primeiramente, é importante destacar que existem diversos tipos de arquitetos

para as mais diferentes tecnologias. Tendo isso em mente, usaremos alguns
exemplos para aprofundarmos nosso entendimento sobre tal profissional: Ao tra-
balharmos em um grande projeto, nos deparamos com a necessidade de usarmos
diversas tecnologias. E para o bom funcionamento deste projeto, eventualmente,
é necessário que se tenha profissionais com conhecimentos específicos nesses

tipos específicos de solução. Desse modo, surge a necessidade da pessoa arquiteta
tecnológica. A sua experiência vai gerar valor ao projeto, baseado na expertise
que ela tem referente a determinada tecnologia.
A Elastic Stack pode ser considerada um bom exemplo da necessidade de ter

técnicos especializados. Essa stack possui um conjunto de ferramentas especí-
ficas. Profissionais tecnológicos especialistas nessas ferramentas conhecerão de
forma profunda sobre Elasticsearch, Kibana, Beats, Logstash e Fleet, e por isso
poderão ser nomeados como pessoa arquiteta tecnológica Elastic. Inclusive, há
uma certificação provida pela empresa Elastic para esse tipo de profissional.
Desse modo, outra pessoa desenvolvedora pode até conhecer um pouco da
Elastic Stack, porém, não compreenderá os detalhes sobre a sua arquitetura.
Outro exemplo que podemos citar é do arquiteto tecnológico Java. Profissional

que, sabe muito além de desenvolver em Java, conhece com profundidade sua
JVM, sendo possível, do mesmo modo, adquirir certificações específicas para
essa tecnologia.
Além desses exemplos, podemos encontrar, ainda, arquitetos focados em bancos

de dados, que normalmente também são DBAs.
A Salesforce e a SAP também possuem tecnologias extremamente específicas,

logo, caso uma organização queira implementá-las em seu sistema, a presença
de um profissional que domine essas tecnologias é fundamental.
Assim, quando uma corporação opta por trabalhar com determinadas tecno-
logias, por suas complexidades, é evidente a necessidade do trabalho de uma
pessoa arquiteta tecnológica para que se possa alcançar êxito em seus projetos.
Arquitetura corporativa
Apesar de sua importância, pouco se ouve falar em arquitetura corporativa, e,

por isso, sua definição levanta dúvidas entre pessoas desenvolvedoras.
Quando pensamos em arquitetura corporativa, precisamos ter em mente que

estamos nos referindo a políticas e regras que impactam estrategicamente a
organização como um todo.
A pessoa arquiteta corporativa, então, poderá fazer a avaliação dos custos que
toda a área de desenvolvimento e engenharia terá para desenvolver os projetos
que farão sentido para um negócio crescer. Esses custos podem ser com Devs,
verticais de desenvolvimento, tipos de tecnologias e licenças. Além disso, essa
pessoa está habilitada também para o planejamento de grandes implementações
tecnológicas. Por meio de sua análise é possível verificar se é necessário ou não
a migração de todos os setores para essa nova tecnologia implementada, por
exemplo. Assim, esse profissional poderá indicar uma possível padronização das
tecnologias dentro da empresa.
Por meio de alguns exemplos será possível compreender melhor a sua relevância
para uma organização. Pensemos em uma situação hipotética em que temos
uma software house ou um grande banco. Nesse contexto, temos milhares de

funcionários, logo, se não houver regras e uma governança sólida, o controle
pode ser perdido e gerar grandes danos à corporação. Alguns questionamentos
devem ser levantados para que seja feito essa governança sólida: como os
funcionários utilizarão as tecnologias? Quais serão as tecnologias? Quais serão
os principais vendors? Normalmente, esses questionamentos serão respondidos
por um arquiteto corporativo.
Outro exemplo prático é quando surge uma nova tecnologia, ou são lançadas
novas versões das ferramentas já existentes, e a empresa precisa analisar se a
migração faz sentido para aquela situação e contexto. Nesse sentido, a pessoa
arquiteta corporativa estará apta para que tal decisão seja tomada da melhor
forma possível.
Outro exemplo é de empresas como a Salesforce, que oferece soluções em CRM

(gestão de relacionamento com o cliente). Essas soluções, ao serem implementa-
das dentro de uma corporação, mudarão culturalmente a forma como o pessoal
de vendas e pós-vendas trabalhará. Nesse caso, um profissional de arquitetura
corporativa avaliará qual impacto isso trará para a companhia, e como aproveitar
essa implementação em outros setores dentro da organização, por exemplo, se
faz sentido também utilizar a nuvem de marketing da Salesforce.
A pessoa arquiteta corporativa é essencial dentro de uma companhia, pois

sem sua avaliação a pluralidade de tecnologias implementadas pode impactar
negativamente os projetos da empresa.
Ela ajudará a alinhar e padronizar, estrategicamente, as áreas dentro da cor-

poração. Fazendo com que as implementações tecnológicas façam sentido e
contribuam para o crescimento do negócio.
Arquitetura de solução
Neste tópico, nos dedicaremos a entender o que é uma pessoa arquiteta de

solução e como essa profissional pode ajudar no dia a dia de uma corporação.
O primeiro ponto que precisamos entender é que o trabalho dessa pessoa fica
entre a área de negócios e a área de software, ou seja, fica em uma área técnica
que busca transformar requisitos de negócio em soluções de software. Isto é, ela
vai enxergar as especificações e as necessidades da organização e fazer isso virar
software.
Um de seus papéis diários é fazer desenhos arquitetônicos da solução para

reproduzir como ela irá funcionar. Profissionais de solução precisam ter a
capacidade de expressar seus pensamentos por meio de desenhos. Obviamente,
existem diversas formas desse profissional desenhar e documentar suas ideias.
Um exemplo é utilizar desenhos em diagrama C4, UML e BPMN para apresentar
como irá transformar algo que está em sua cabeça em solução de software.
Outro papel que também pode ser atribuído a essa pessoa é o de analisar os
impactos comerciais em relação a uma escolha tecnológica. Por existir diversas
formas de solucionar uma necessidade dentro de uma empresa, ela escolherá,
pelo contexto do cliente, qual será a melhor solução possível, levando em

consideração tanto aspectos técnicos quanto comerciais.
Vamos imaginar, por exemplo, que todo software legado de uma companhia
está utilizando a AWS, não fará sentido fazer esse cliente migrar toda sua
infraestrutura para o Google, somente por uma opinião de que o Google é
melhor, a não ser que exista, por exemplo, um ponto financeiro que será
impactado positivamente com a mudança. Ou seja, toda escolha vai depender
do contexto da organização. Outra situação, seria se toda base de dados de um
sistema de uma empresa estivesse utilizando Oracle; não podemos mudar para
SQL Server se não fizer muito sentido para o crescimento da corporação.
Outra função que a pessoa de solução pode assumir é a de participar de

reuniões com clientes na etapa de pré-venda e/ou venda para apresentar detalhes
técnicos de como a solução poderá agregar valor ao negócio. Geralmente, a
empresa envia para essas reuniões consultores que irão negociar com os clientes,
porém, esses não são profissionais extremamente técnicos. Eles compreendem o
funcionamento do software, o sistema de precificação e a negociação, porém
caso seja necessário apresentar detalhes mais técnicos, arquitetos de solução
poderão demonstrar ao cliente como que, tecnicamente, a solução poderá ser
implementada. Além disso, arquitetos poderão analisar os impactos de custos
da implementação deste software para o negócio. Um exemplo dessa análise
é quando uma empresa opta por implementar um sistema CRM. O consultor
poderá apresentar a solução de forma geral, algo menos técnico, porém, o
entendimento profundo de como a solução pode impactar a organização, a

metrificação de algo mais técnico como integrações e migrações, será melhor
apresentada por uma pessoa arquiteta de solução, já que ela conseguirá gerar
um pouco mais de previsibilidade sobre todos esses pontos que a empresa terá
que trabalhar durante a implementação da solução.
O que é arquitetura de software
Para compreendermos um pouco mais sobre arquitetura de software é impor-

tante sabermos que esta é uma disciplina da engenharia de software. Quando
falamos em engenharia de software, estamos nos referindo a todos os processos
de desenvolvimento de uma solução, desde as metodologias até o formato em
que o software será desenvolvido. Ou seja, essa engenharia compreende que
existe um ciclo de desenvolvimento para criação de um software. E a arquitetura
de software contribuirá para que esse ciclo aconteça.
Existem diversas definições válidas para arquitetura de software. Desde defini-

ções mais formais até algumas mais informais. Inicialmente, vamos definir essa
arquitetura como a relação entre os objetivos de um negócio e suas restrições
com os componentes a serem criados e suas responsabilidades, visando sua
evolução.
Todo negócio, ao implementar um software, tem um objetivo a ser atingido,

mas restrições financeiras, de equipe e tecnológica, por exemplo, podem afetar o
processo de construção dessa aplicação. A pessoa com habilidades arquitetônicas

poderá contribuir no processo de construção da solução para que essa se adapte
às restrições presentes na corporação.
Além disso, essa pessoa poderá contribuir para que se possa desenvolver uma
solução que mantenha uma relação bem estruturada entre seus componentes,
fazendo com que esses atendam os objetivos do negócio. Isto é, ela poderá fazer
com que esses componentes, em conjunto, apesar das restrições, consigam gerar
uma solução de alta qualidade que irá atender as necessidades da corporação.
Outra definição mais formal é a da ISO/ IEC/IEEE 42010. Este instituto define
arquitetura de software como “…a relação de um sistema e seus componentes,
suas relações, seu ambiente, bem como os princípios que guiam seu design e
evolução”. Normalmente quando desenvolvemos um software não pensamos
apenas em curto prazo, pensamos, ou deveríamos pensar, em como esse software
vai evoluir a médio e a longo prazo. Logo, a pessoa arquiteta de software vai
pensar nos componentes atuais da corporação e em como esses poderão evoluir
dentro de uma solução. Ou seja, apresentará o desenho de um software, de fato,
sustentável.
A lei de Conway pode nos ajudar a entender um pouco mais como funciona a
arquitetura de software. Melvin Conway diz que “organizações que desenvolvem
sistemas de software tendem a produzir sistemas que são cópias das estruturas de
comunicação dessas empresas”. Vamos imaginar um exemplo prático: uma com-
panhia decide implementar um sistema de software. Nessa corporação, há um
desenvolvedor Backend, um desenvolvedor Frontend e um DBA. Provavelmente,

quando essa aplicação for desenvolvida, teremos uma solução Backend que vai
se comunicar com o banco de dados e certamente, também uma SPA (Single
Page Application) Frontend para se comunicar com Backend. Porém, se na
organização houver somente um profissional Backend e um DBA, dependendo
da situação, o frontend da aplicação será uma parte do projeto principal rodando
em conjunto com backend. Então, resumidamente, a arquitetura do software vai
ser desenvolvida de acordo com os times disponíveis para o projeto.
Assim, podemos dizer que o processo de arquitetar um software estabelece que o

que está sendo desenvolvido faça parte de um conjunto maior que, normalmente,
é o negócio.
Arquitetura de software x arquitetura de solução
Por existir um ponto de intersecção entre a arquitetura de software e a arquite-

tura de solução, seus conceitos são, muitas vezes, confundidos. O que precisamos
ter em mente é que a arquitetura de software representa algo mais baixo
nível se comparada com arquitetura de solução. A arquitetura de software está
diretamente ligada ao processo de desenvolvimento do software, seus padrões,
qualidade de código, boas práticas, bem como sua estrutura.
A pessoa arquiteta de software poderá contribuir diretamente na estrutura

organizacional de uma empresa, ou seja, dependendo da arquitetura de um
sistema, ela poderá definir a divisão dos times dentro da organização. Em
outras palavras, dependendo dos componentes que o software terá, essa pessoa
auxiliará na seleção dos profissionais que farão parte do projeto. Diferentemente
da pessoa arquiteta de solução que quase sempre aborda aspectos de alto nível,
sendo que raramente chegará a trabalhar diretamente com código.
O papel do arquiteto de software
Apesar de nem todas as organizações possuírem o cargo de pessoa arquiteta

de software, normalmente profissionais mais experientes como desenvolvedores
seniors e tech leads acabam realizando esse papel baseado em suas experiências
anteriores.
O principal papel que essa pessoa pode assumir é a função de transformar

requisitos de negócios em padrões arquitetônicos. Ou seja, ela vai pensar em
como atender a alguns requisitos da empresa os transformando em uma solução.
Para isso irá utilizar seus conhecimentos sobre padrões arquitetônicos.
A pessoa arquiteta é, na maioria das vezes, um desenvolvedor e em seu dia a dia

pode orquestrar o fluxo de comunicação entre pessoas desenvolvedoras e experts
de domínio. A necessidade de ter um expert de domínio trabalhando junto com
o desenvolvedor surge por existir, normalmente, uma dificuldade em alinhar o
que vai ser desenvolvido com o que o cliente precisa. Esse expert é uma pessoa
que sabe da necessidade da organização, ou na maioria das vezes é a pessoa que
vai utilizar o software no dia a dia. A pessoa arquiteta poderá facilitar o fluxo de
comunicação entre esses dois profissionais, para que a aplicação seja produzida
do jeito esperado.
Em outras palavras, por ser cada vez mais natural que as equipes tenham
autonomia para tomar decisões de design e arquitetura, é muito evidente que a
grande pressão do dia a dia faça com que o software tome caminhos arquiteturais
diferentes do que se havia planejado para garantir sua sustentabilidade, assim
como na garantia do atendimento dos atributos de negócio; por conta disso, um
arquiteto ou arquiteta de software deve se fazer presente nos projetos.
Ainda sobre o papel dessa pessoa, entender profundamente sobre conceitos e

modelos arquiteturais é essencial para que a pessoa arquiteta consiga auxiliar
na resolução de problemas. Por vezes é comum que um profissional queira
solucionar um problema baseado apenas em sua experiência. Um bom exemplo
disso é quando um desenvolvedor costuma criar sistemas monolíticos. É comum
que nos próximos desafios esse profissional queira resolver as situações de forma
monolítica. Porém, quanto mais uma pessoa entende de modelos arquiteturais,
maior vai ser a diversidade de possibilidades para resolução de desafios, pois
ela conseguirá entender como se pode contextualizar o desafio para conseguir
resolvê-lo da melhor forma possível. Isso tudo, não apenas pela nomenclatura
de arquiteto, que algumas vezes nem é presente na organização, mas porque
normalmente esse arquiteto já tem muita experiência, isto é, já vivenciou muitas
situações e quando se vê frente a um desafio, como por exemplo um atraso na
entrega ou insatisfação do cliente. Essa pessoa é capaz de se reunir com o time e,
baseado em sua experiência, poderá propor uma variedade de possibilidades que,

tecnicamente falando, poderão ajudar a equipe. É importante dizer que muitas
dessas situações não estão previstas no negócio, nem no calendário de entrega,
mas fazem parte do processo.
Outro papel importante da pessoa arquiteta é reforçar boas práticas de desenvol-

vimento. Isso é feito através de testes, trabalho com SOLID, conexões e com ban-
cos de dados. Essa profissional poderá fazer os seguintes questionamentos: Como
essa solução irá funcionar? Vai utilizar clean architecture? Vai trabalhar com
eventos? Ou seja, nitidamente, por ser uma pessoa que está diretamente ligada ao
software que está sendo desenvolvido e, apesar de sua visão não abordar aspectos
de alto nível como a do arquiteto de solução, ela está preocupada com o “if” que o
desenvolvedor está fazendo. Mesmo tendo criado e organizado os componentes
arquiteturais ela irá contribuir, durante o processo de desenvolvimento, para que
essa solução tenha um padrão de qualidade garantido.
Code reviews
Algo comum na carreira de um arquiteto de software é que, por ser além de

desenvolvedor, ele poderá participar de mais de um projeto ao mesmo tempo e
por esse motivo não tem disponibilidade para ficar codificando com outros devs.
Nessa situação, ele pode ser uma das pessoas atribuídas para fazer code reviews,
para que dessa forma ele possa validar se os componentes e os requisitos de
arquitetura definidos estão presentes na solução.
Departamento de arquitetura na empresa
Há empresas que apesar de não possuírem formalmente o cargo de arquiteto de

software, possuem um departamento de arquitetura que auxilia os diversos times
da organização com questões arquiteturais. Esse departamento pode dar suporte
aos desenvolvedores. Os devs desse departamento conseguem visualizar todos
os projetos e microsserviços funcionando e como a empresa está avançando
tecnologicamente. Ao surgir um novo projeto na organização essa equipe
de suporte arquitetural poderá auxiliar os desenvolvedores por meio de uma
avaliação. Nessa avaliação, será analisado se aquele projeto já existe, ou existiu,
e nestes casos poderá sugerir a utilização desses projetos já existentes ao invés de
criação de novos. Além disso, esse setor avalia também toda documentação que
descreve o software, podendo dizer se está falha ou com padrões inadequados.
Logo, mesmo não tendo um arquiteto de software como cargo específico, a

organização tem devs que trabalham nessa área arquitetural para aprovar e
auxiliar as equipes de projetos a tomarem as melhores decisões, alinhadas ao
contexto da organização.
Além disso, a área de arquitetura monitora, gerencia os processos de mudança

e garante a governança, reforçando assim um padrão de qualidade em todos os
projetos.
Apesar de muitos entenderem que áreas como essa podem burocratizar o

processo de desenvolvimento e retirar a liberdade dos devs, é evidente que
quando há uma grande quantidade de equipes, sistemas e tecnologias envolvidas,

é imperativo que haja controle para garantir a sustentação de todo o ecossistema
a médio e a longo prazo. Isso reforça a ideia de que a criação desse setor
em uma corporação não tem a intenção de controlar o trabalho de outros
desenvolvedores. A ideia é que os profissionais dessa área consigam consolidar
seus conhecimentos sobre o contexto da empresa para ajudar e apoiar os devs
que estão criando projetos no dia a dia.
Pelo fato das corporações não utilizarem a nomenclatura de arquiteto é comum

vermos tech leads assumindo essa posição por tomarem decisões totalmente
arquiteturais.
As vantagens de aprender arquitetura de software
Mesmo que eventualmente não exista o cargo de pessoa arquiteta formalmente

na maioria das empresas, pessoas desenvolvedoras atribuídas a cargos de li-
derança técnica muitas vezes acabam tomando decisões arquiteturais fazendo
assim, informalmente, esse papel.
Ter conhecimento sobre arquitetura permite navegar da visão macro para a visão
micro de um ou mais software. Dessa forma, é possível visualizar aspectos de
alto nível e de baixo nível dentro da solução. Com isso, podemos perceber que o
código é um componente que se relaciona com outros. Podemos garantir também
que esses componentes sejam construídos de modo que possam ser desacoplados
caso isso seja necessário para sua evolução.
A pessoa desenvolvedora, ao estudar arquitetura, compreende quais são os

diversos protocolos para desenvolver a mesma solução, e partindo disso ela
poderá escolher a melhor opção para determinada situação e contexto. Um dev
que entende como os componentes se relacionam saberá quais são as formas
arquitetônicas para trabalhar como por exemplo CQRS, Arquitetura baseada
em eventos, etc. Também, essa pessoa poderá avaliar quando um sistema deve
ser ou não monolítico. Esses conhecimentos possibilitam, ainda, que a pessoa
desenvolvedora pense no projeto a longo prazo, isto é, na sustentabilidade; nos
aprofundaremos neste tema mais adiante. Quando desenvolvemos um software
é muito comum que tenhamos prazos pouco flexíveis e isso acaba criando uma
tendência pela busca de resoluções a curto prazo. Através dos conhecimentos
sobre arquitetura, mesmo com prazos curtos, é possível modelar o software de
forma que seja mais fácil mantê-lo a longo prazo. Lembrando que o papel do
desenvolvedor é conseguir fazer com que esse software retorne o valor para a
empresa. Se ao passar dos anos essa solução não puder evoluir, eventualmente
a solução pode ter trazido mais prejuízo do que valor para a organização.
Trabalhar com arquitetura de software de forma intencional pode definir o

sucesso ou fracasso de um projeto. Pois o sucesso de um projeto não está na
primeira entrega, mas sim nas evoluções subsequentes.
Por não conhecerem muitas possibilidades para solucionar desafios, é comum

que desenvolvedores pouco experientes fiquem interessados em implementar
novas tecnologias assim que são lançadas. Eles acreditam que essa nova tecno-
logia é a melhor forma de solução para as diversas situações presentes em uma

organização. Porém, é necessário que se compreenda se essa nova tecnologia
atende os objetivos daquela corporação. Isso só é possível caso a pessoa tenha
uma visão macro e micro do negócio para saber exatamente qual será impacto
daquela tecnologia no projeto, e se vale a pena usá-la ou não naquele momento
e contexto. Sem dúvidas ter conhecimentos sobre arquitetura faz com que essa
pessoa desenvolvedora consiga tomar decisões de forma mais racional, evitando
assim ser influenciado por “hypes” de mercado.
Ao aprender sobre a visão macro e micro de uma solução a pessoa poderá ter
mais clareza do impacto que o software possui na organização como um todo
e não apenas em uma área. Esse senso de pertencimento, ou seja, de saber
exatamente como seu trabalho afeta toda corporação, tem benefícios para a sua
carreira, bem como para manter sua motivação profissional por saber que seu
trabalho é significativo.
Quando um dev não compreende totalmente os conceitos de arquitetura, isso

pode limitá-lo ao processo de solucionar problemas, gerando eventualmente
insegurança na tomada de decisão. O entendimento de arquitetura não será
necessariamente uma “bala de prata”, porém sem dúvidas será um ponto de
partida na busca por soluções.
É importante saber também que aprender sobre arquitetura nos traz a necessi-
dade de mergulharmos em padrões de projetos e de desenvolvimento e suas boas
práticas. Ou seja, a arquitetura nos força estudar quais foram os padrões que
outras pessoas já utilizaram para resolver diversos tipos de problemas, fazendo

com que possamos ganhar tempo no processo de desenvolvimento, além de
termos a possibilidade de padronização da solução, trazendo mais clareza a
outros profissionais que eventualmente poderão ter contato com a aplicação.
Arquitetura vs Design de software
Existe uma linha de pensamento que afirma que arquitetura e design de software
são a mesma coisa. Neste tópico, faremos algumas reflexões sobre essas duas
áreas e, assim, iremos perceber que, de certo modo, essas áreas podem ser
consideradas distintas.
Quando falamos em arquitetura de software, estamos nos referindo ao escopo

global de um software, ou seja, visualizar esse software em um nível mais
alto. Conseguimos ver a componentização, a comunicação e as abstrações
dessa solução. Por outro lado, quando falamos em design de software estamos
apontando para um escopo mais local, isto é, mais baixo nível. Podemos
pensar nos seguintes questionamentos: como deixar uma classe com menos
responsabilidade? Como implantar patterns para facilitar nossa estratégia? As
respostas para essas questões podem ser consideradas decisões de design de
software.
A citação do Elemar Jr pode nos ajudar a entender melhor os conceitos sobre

essas duas áreas: “Atividades relacionadas à arquitetura de software são sempre
de design. Entretanto, nem todas as atividades de design são sobre arquitetura.
O objetivo primário da arquitetura de software é garantir que os atributos de

qualidade, restrições de alto nível e os objetivos de negócio sejam atendidos pelo
sistema. Qualquer decisão de design que não tenha relação com este objetivo
não é arquitetural. Todas as decisões de design para um componente que sejam
“visíveis” fora dele, geralmente, também não são”. Logo, sempre que falarmos
de arquitetura estaremos nos referindo também à design, pois até mesmo para
desenvolver um componente é necessário utilizar aspectos de design, entretanto,
nem todas as atividades de design podem ser consideradas arquiteturais. Normal-
mente, ao pensar em arquitetura, estamos falando de requisitos não funcionais
e, ainda, restrições de alto nível.
Por exemplo, para que logs de um sistema possam ser centralizados e facilmente
recuperados, a Elastic Stack será utilizada. Podemos perceber que tal decisão
afetará a aplicação como um todo, além da possível contratação de mais
infraestrutura para que a Elastic Stack seja instalada, ou mesmo, uma eventual
contratação de um serviço gerenciado na Elastic Cloud. Decisões como essa
podem afetar todos os sistemas de uma organização, seu orçamento, o tempo
em que um possível bug pode ser corrigido, a forma com que cada time
trabalhará no dia a dia com a observabilidade, além do conhecimento básico na
Stack que será requerida por cada desenvolvedor e eventuais treinamentos que
os mesmos deverão receber para operar ferramentas. Decisões que impactam
diretamente em quais componentes e vendors que um projeto utilizará são
decisões arquiteturais.
Por outro lado, quando tomamos decisões de quais patterns GoF (Gang of Four)
o projeto utilizará; SOLID, DRY, Clean code, a quantidade de camadas de uma
aplicação, estamos nos referindo fundamentalmente ao design do software.
Pilares da arquitetura de software
Para compreendermos o processo de arquitetar um software é importante

separarmos alguns de seus conceitos em pilares, isso facilitará nosso enten-
dimento. Vamos organizar nossos estudos nos seguintes tópicos: organização,
estruturação, componentização, relacionamento entre sistemas e governança.
Organização
Quando falamos em arquitetura, falamos em organizar um sistema (não o

software em si) que possibilite a fácil componentização, evolução, bem como
um fluxo rico para que possamos atender os objetivos de negócio gerando um
produto para o cliente final.
Estruturação
Estruturar um software significa organizá-lo para que este seja de fácil evolução
e componentização. Além disso, a solução precisa atender os objetivos de
negócios, tendo componentes com estruturas claras. Sem isso não é possível criar
um software de qualidade e que consiga evoluir com o passar do tempo.
Componentização
Uma solução pode ser o conjunto de diversos sistemas e, dependendo da

interpretação, eventualmente esses sistemas precisam se comunicar, por isso
é necessário compreender como componentizar uma solução. Isto é, entender
como um sistema pode se relacionar com os outros. É através da junção de
componentes que nós conseguimos atingir os atributos de qualidade do sistema.
Devemos pensar em todo ecossistema que existe em torno do processo que nós
pretendemos fazer até o resultado final, já que esses componentes serão usados
em diversos momentos do nosso trabalho.
Grande parte do trabalho no mundo da arquitetura de software envolve dominar

as formas de realizar a componentização dos processos para que eles operem com
eficácia, evitando o retrabalho. Podemos dizer então que a componentização é a
base na criação de um software.
Relacionamento entre sistemas
Dentro de uma corporação é comum que se tenha mais de um software. Por isso
é importante que, ao desenvolvermos uma aplicação, saibamos como preparar
seus componentes para que esses consigam se integrar de maneira eficiente
dentro de um processo maior. É necessário, então, observar se os protocolos
estão apropriados, se as redes estão sendo usadas de modo necessário e se as
regras de segurança estão sendo efetivas.
Governança
Principalmente nas grandes empresas a vasta quantidade de sistemas e integra-

ções são cada vez maiores. Muitas pessoas veem a governança como uma forma
de burocratizar o processo de desenvolvimento; porém, na grande maioria das
vezes, o software a ser desenvolvido é apenas mais um dentre as centenas de
outros que já estão em operação. Logo, é necessário que se tenha padronização,
regras e documentação. Ou seja, definições que fiquem claras para todos os
colaboradores. Por exemplo, quais linguagens serão utilizadas? Quais protocolos
serão aplicados? Quais sistemas serão utilizados para se comunicar? É necessário
ter o mínimo de governança para que essa solução se integre às demais e consiga
evoluir naquele ambiente.
A governança busca a garantia de que o software continue funcionando indepen-

dente de equipe. Tendo um requisito base de governança, teremos a segurança
de que as pessoas que trabalham nessa aplicação sejam dispensáveis. Quando
falamos dispensáveis, não estamos falando do valor dessas pessoas dentro da
corporação, mas sim sobre poder substituir esses profissionais em caso de
eventuais mudanças. Com regras e protocolos definidos se torna mais rápida
a adaptação de novos devs, caso seja necessário, para o projeto não se perder.
Além disso, ao se fazer tão necessário em um projeto um desenvolvedor poderá
perder uma possível promoção dentro de sua organização. Quando isso acontece,
sua carreira é afetada negativamente, pois a dependência dessa pessoa no projeto
impossibilita sua evolução.
Requisitos Arquiteturais (Ras)
Quando desenvolvemos um software, principalmente na parte de planejamento,

é visível que, para que essa solução seja bem construída, necessitamos de
requisitos bem definidos. Para isso, pensamos em como esses aspectos irão
impactar diretamente a arquitetura do nosso software. E caso esses não sejam
funcionais, muitas vezes podem ser considerados como requisitos arquiteturas
(Ras).
Hoje em dia, com o modelo de Squad, isto é, cada time criando seu próprio
software e entendendo como as coisas funcionam, raramente vemos Ras de um
modo formalizado. Antigamente, trabalhávamos muito com vários documentos
do excel, um requisito por vez, ou seja, cada detalhe de todos os requisitos
arquiteturais separadamente e podíamos ver RAs formalmente dentro das
organizações.
Atualmente, apesar desses requisitos serem mais vistos quando falamos em

arquitetura de solução, é importante, ao desenvolvermos um software, que
tenhamos conhecimento, ao menos o básico, de requisitos arquiteturais. Quando
compreendemos esses requisitos, podemos planejar a arquitetura da aplicação da
melhor forma possível.
Para facilitar nosso entendimento, separamos alguns requisitos que conside-

ramos essenciais ao nosso estudo: performance, armazenamento de dados,

escalabilidade, segurança, legal, audit (auditoria) e marketing.
Performance
Dizemos que se trata de um requisito de performance quando, em uma aplicação,

temos uma regulação com o limite de requisições preestabelecido, por exemplo,
de 500 milissegundos. Outro ponto importante é o throughput dessa aplicação -
se tivermos uma máquina com 1000 millicores rodando e precisarmos aguentar
50 transações por segundo, esse também será um requisito de performance.
Armazenamento de dados
Quando uma empresa, eventualmente fecha contrato com a AWS, por exemplo,
e a equipe precisa se adaptar para utilizar seus bancos de dados, inclusive
o DynamoDB. Dizemos que essa adaptação está relacionada a um requisito
arquitetural de armazenamento de dados.
Outra situação ocorre quando os dados precisam cumprir regulações, ou seja, se

o software estiver rodando na Europa precisa ter um datacenter europeu. Não
é apenas uma questão tecnológica mas sim de praticar a compliance dentro da
organização. Ou seja, estar de acordo com uma regra e com a legislação vigente.
Isso vai gerar valor ao negócio e poderá contribuir para sua permanência no
mercado.
Escalabilidade
Para pensarmos em escalabilidade precisamos ter em mente como esse software

vai escalar. Verificaremos se ele vai escalar horizontal ou verticalmente. Outro
ponto que veremos neste requisito é se podemos optar pelo uso do load balancer
para facilitar o bom funcionamento do sistema em caso de um congestiona-
mento.
Segurança
Quando trabalhamos com E-commerce é muito comum recebermos transações

via cartão de crédito. Estas precisam estar com certificações PCI, por exemplo.
Além disso, pode surgir a necessidade de um sistema rodar criptografado ou
a comunicação entre os microsserviços precisarem rodar usando Mutual TLS.
Essas situações podem ser consideradas de requisito arquitetural relacionada à
segurança.
Legal
Como já foi dito, precisamos observar quais são os requisitos legais para que
nós possamos cumprir a legislação vigente de cada país. No Brasil, temos a
LGPD (Lei Geral de Proteção de Dados), extremamente necessária para que seja
possível construir mecanismos que evitem ao máximo o vazamento de dados.
Audit
Ao criarmos projetos precisamos garantir que existam parâmetros e formas

de auditorias. Isso nos permite entender como fazer verificações de maneira
eficiente.
Alguns questionamentos podem nos guiar em relação a esse requisito: onde a

aplicação estará logada? Como conseguir logar? Por quanto tempo o dado ficará
retido? Esses aspectos são importantes, pois tudo o que acontece em um sistema
precisa estar em logs.
Marketing
Caso nossa aplicação precise participar de campanhas de marketing, ela preci-

sará ter disponibilidades específicas para sustentar os diversos pontos ligados
ao marketing. Precisaríamos, por exemplo, ter regras para garantir que nossa
solução consiga trackear de onde vem cada acesso. Desse modo, será possível
garantir que cada tipo de acesso em nosso sistema esteja cacheado mais próximo
do usuário para garantir um acesso mais personalizado.
Requisitos arquiteturais na prática
A forma mais comum de fazer/organizar os requisitos arquiteturais é através

de planilhas. Podemos nos reunir com experts de domínio e com o executivo
para fazermos alguns questionamentos que poderão nos auxiliar a montar os

documentos que nos guiarão na tomada de decisão de RAs. Durante a reunião,
podemos fazer algumas perguntas para, assim, adequar nossa solução à melhor
arquitetura. Por exemplo, quais setores irão utilizar a solução? Os clientes
que irão acessar o software serão somente internos, ou internos e externos?
Esses questionamentos também podem ser feitos a pessoas de departamentos
específicos da empresa, por exemplo, fazer esse levantamento no setor jurídico.
Isso vai depender da funcionalidade da aplicação que pretendemos desenvolver.
No dia a dia, não vemos esse tipo de organização sendo feita com frequência.
Geralmente as coisas acontecem de maneira mais orgânica e flexível, mesmo em
corporações de grande porte com diversas restrições como os bancos. Porém, de
uma forma ou de outra, requisitos existem e muitas vezes ficam subentendidos.
O que devemos levar em consideração é que quanto mais clareza nós tivermos
do tipo de software que iremos criar, ou seja, dos requisitos arquiteturais que
teremos que utilizar, mais clareza teremos no processo de desenvolvimento.
Desse modo, poderemos evitar ruídos quando nossa aplicação estiver no ar.
Características Arquiteturais
Sempre que desenvolvemos um sistema, de uma forma ou de outra, este possui

características arquiteturais. E algumas vezes essas características são ruins. Isso
acontece quando não se pensa de maneira intencional em aspectos específicos
ao projetar a solução. Quando estamos trabalhando com arquitetura de software,
isto é, desenvolvendo algum sistema é importante entender como estruturá-lo

de maneira intencional.
Compreender a estrutura do software facilita a visão de forma intencional nos

pontos que poderão impactar a solução. Se não tivermos uma visão geral de
como trabalhar intencionalmente com a arquitetura de um sistema, podemos ter
dificuldade para resolver alguns problemas que eventualmente surjam durante
o seu processo de evolução.
Trabalhar baseado em uma intenção significa estar preparado para resolver de-
terminados problemas. Caso não tenhamos uma base de arquitetura no processo
de desenvolvimento talvez até consigamos resolver um problema indiretamente.
Porém, isso significaria contar com a sorte, e nisso não existe garantia de que o
nosso sistema irá funcionar conforme o esperado.
Por exemplo, sabemos que um software precisa ser resiliente, ou seja, ele precisa
se adaptar em momentos de crise e se recuperar rapidamente, ou ter um plano
“B” para que não deixe de funcionar diante das dificuldades (adversidades).
Vamos imaginar que quando estamos desenvolvendo um sistema não tenhamos
pensado em resiliência de maneira explícita, ou seja, de forma intencional. Mas
ao utilizarmos bibliotecas, com infraestrutura montada e com muitos aspectos
pré-definidos, essa resiliência acaba sendo feita, de maneira embutida e de graça,
podemos dizer de modo natural. A conclusão é que nosso sistema pode até ser
resiliente, mas isso foi conseguido de modo não intencional. Isso aconteceu
por sorte, funcionou mas poderia não ter funcionado. Nesse caso, sabemos
que não é interessante dependermos de sorte em nossas aplicações. A frase

de Thomas Jefferson pode nos ajudar a refletir sobre a importância de estar
preparado: “quanto mais trabalho para resolver determinado problema mais eu
tenho sorte” (adaptado). Então, se queremos ter a garantia de “sorte” quando
vamos desenvolver software, precisamos estar preparados para verificar pontos
e características que devem ser levadas em consideração e são essenciais ao bom
funcionamento dessa solução, ou seja, considerar as características arquiteturais.
É importante dizer que, normalmente, muitas dessas características são requi-

sitos não funcionais do seu sistema, isto é, não são requisitos de necessidade
explícita e de regras de negócio focadas no que o cliente pediu, mas sim requisitos
que vão conseguir nos trazer a garantia de que o sistema trabalhe e suporte a
carga. Conseguir de forma geral se manter online da melhor forma possível.
Para compreendermos melhor essas características, vamos dividi-las em três

áreas. A primeira área que veremos são as operacionais, em seguida abordaremos
a área de características estruturais e por último as Cross-Cutting. Assim
veremos especificamente aspectos que permeiam todo o software.
Características Operacionais
A forma como desenvolvemos uma solução poderá impactar na operação desse

sistema. Por esse motivo abordaremos, neste tópico, características arquiteturais
focadas em aspectos operacionais. Nesse contexto, o nosso objetivo aqui não é
que você seja um expert em criar subnets ou, ainda, um expert em gerenciar
backups, por exemplo. Porém, é importante que você saiba como facilitar essas
operações. Outro ponto importante, é que possamos compreender como um
possível backup pode afetar a performance de nossa aplicação. Resumidamente,
tudo que é operacional, normalmente, são coisas que não iremos fazer mas que
devemos permitir que sejam operadas em nosso software.
Disponibilidade
O primeiro item que podemos destacar relacionado a características operacionais

é a disponibilidade.
Geralmente, quando desenvolvemos uma aplicação, pensamos apenas em como

colocá-la no ar, mas não pensamos em o quão disponível deixaremos essa
solução. E focar especificamente nisso é algo que pode fazer muita diferença
na qualidade do nosso sistema.
Sempre que vamos criar um software, podemos pensar em como garantir que
esse esteja disponível. Podemos pensar, por exemplo, se essa solução ficará no ar
24/7. O nível de SLA, que é o quanto combinamos com o cliente, e de SLO, que
são os objetivos que queremos garantir para o cliente.
Assim, pensar em como verificar a disponibilidade pode desencadear uma série

de aspectos, por exemplo, a observabilidade. Neste contexto, podemos usar
técnicas de SRE e, desse modo, fazer um nível de budget de indisponibilidade. Ou
seja, se hipoteticamente podemos ficar indisponíveis somente uma vez por ano
durante 1h. Caso fiquemos 20 min indisponíveis, logo teremos somente mais 40
min para ter essa indisponibilidade durante o restante do ano. Assim, precisamos
saber como verificar esses incidentes.
Recuperação de desastres
Outro aspecto relacionado à disponibilidade é a recuperação de desastres. Pre-

cisamos pensar intencionalmente em como recuperar um sistema quando esse
estiver fora do ar. Isso é importante, pois conforme estivermos trabalhando com
sistemas, estes podem passar a ter missões cada vez mais críticas. Por exemplo,
se estivéssemos trabalhando em um site de uma padaria e o negócio ficasse fora
do ar por uma hora, muito provavelmente o dono do negócio nem perceberia.
Porém, se um sistema tem missão mais crítica e começa a ficar indisponível,
isso pode gerar um problema muito grande para a empresa. No segundo caso,
é necessário, então, ter processos específicos para amenizar as consequências
da indisponibilidade. Além disso, criar estratégias para mitigar o problema e
conseguir evitar que este ocorra novamente.
Outro exemplo é se, por algum motivo, caísse uma região AWS em que nosso
sistema está. O quanto estaríamos dispostos a pagar para trabalharmos com
multirregião ou para trabalharmos com multicloud. Todos esses aspectos devem
ser levados em conta.
Performance
Ao projetarmos uma aplicação é importante que pensemos que esta precisa ser
performática. Nesse sentido, falaremos basicamente sobre throughput, que a
capacidade de receber e processar requisições. É essencial pensarmos intenci-
onalmente no quanto de performance queremos ter, ou seja, o quanto nosso
sistema precisa suportar. Por exemplo, digamos que temos duas situações, na
primeira um sistema que precisa suportar 5 mil requisições por segundo e na
segunda situação um que precisa suportar 50 requisições por segundo. Esses
sistemas precisam ser arquitetados de maneira diferente. Talvez, a segunda
situação não precise que trabalhemos com CQRS, mas na primeira situação
essa opção é necessária. Pensamos em performance principalmente quando
trabalhamos de forma intencional.
Recuperação (backup)
Pode existir uma dificuldade de pensar nesse aspecto, principalmente por ser
comum surgir a ideia de que a necessidade do backup está associada a algo ruim
que aconteceu em nossa aplicação. O problema é que quando não temos essa
reflexão podemos precisar do backup e este não estar disponível. Ultimamente
nós podemos ficar, de certo modo, tendenciosos a confiar na nuvem como que
sempre garantirá toda disponibilidade que você precisa, por outro lado, temos
que lembrar que trabalhar com computação em nuvem significa trabalharmos
com um sistema de responsabilidade compartilhada.
Assim, é importante que criemos regras e políticas específicas onde a cada

quantidade de tempo pré-determinado exista um teste de backup. Podemos,
ainda, criar uma política para deixar o backup em redes separadas. Isso será
eficiente pois caso nossa aplicação sofra um ataque de ransomware, nosso
backup não será criptografado junto. Lembrando que, nossa aplicação pode ter
missão crítica para empresa e por isso é extremamente importante pensarmos
em como garantir o backup nos dias atuais.
Confiabilidade e segurança
Provavelmente, teremos que pensar em aspectos específicos de confiabilidade e

segurança quando estivermos trabalhando com sistemas de missão crítica. Para
isso, é preciso que saibamos onde estão os pontos de dificuldade e onde ocorrem
mais incidentes relacionados à defesa da nossa aplicação. Em algumas situações,
por considerarmos esses aspectos relativamente básicos, podemos negligenciá-
los. Por exemplo, digamos que para criação de uma conta em determinada
solução que estamos desenvolvendo fosse necessário apenas login por uma rede
social ou digitar um e-mail para que a conta seja criada automaticamente,
isto é, o usuário precisa se esforçar minimamente para criar a conta. Caso
o usuário, por algum motivo, digitasse o email errado, e não fosse validado
naquele momento, sabemos que iria entrar um “lixo” no banco de dados, mas
com rotinas esporádicas para limpeza conseguiríamos eliminar esse email. O
grande problema é se, em algum momento, tivermos pessoas mal intencionadas

que resolvam fazer robôs para ficar acessando nosso endpoint para criar contas
fakes em nosso sistema. Isso tudo tem a ver com confiabilidade.
Quando pessoas tentam fazer brute force para entrar e fazer login em uma
plataforma, também podemos considerar como um exemplo de como aspectos
de segurança precisam ser pensados de maneira intencional. Essas pessoas
podem colocar robôs para rodar e tentar descobrir a senha dos usuários, o que
acaba gerando um número grande de requisições. Sabemos que a maioria dos
sites possuem regras e políticas de senhas fortes que dificultam a quebra de
senhas. Porém, quando essa pessoa mal intencionada faz vários brute force acaba
afetando o banco de dados, a velocidade, utilização da CPU, etc. Imaginemos
que uma situação semelhante a essa aconteça durante um evento, ou seja,
comecemos a receber vários acessos a ponto de percebermos que nosso POD
no kubernetes começou a escalar descontroladamente. Isso pode significar que
estamos recebendo milhões de requisições de robôs, vindo de vários lugares dife-
rentes. A primeira solução seria colocarmos um Captcha e de fato é uma ótima
solução. Porém essa alternativa não resolve tudo. Poderá resolver o problema de
segurança mas já teríamos recebido as milhares de requisições e nosso sistema já
estaria afetado. Imaginemos, então, um cenário mais complicado: se durante um
evento de vendas ficássemos indisponíveis, geraria um transtorno imenso para
empresa, por não ser possível realizar as vendas. Observe que nossa aplicação
precisa ter camadas adicionais de segurança para continuar funcionando mesmo
frente a esses tipos de ataques.
Robustez
Falamos em sistemas robustos quando a aplicação além de confiável está em

uma estrutura robusta o suficiente para conseguir escalar, caso seja necessário.
Inicialmente, é importante termos em mente as seguintes informações, primeiro
a cloud não é infinita. E segundo, existem muitas empresas que rodam mais de
100 mil instâncias simultaneamente. Com essas informações, vamos imaginar
que caiu uma região da AWS em que nossa aplicação estava, e essas máquinas
precisam evacuar de uma região para outra para conseguir manter a disponibi-
lidade. O problema é que em outra região não havia capacidade operacional de
ter tantas máquinas no ar rodando. Então, mesmo que tenhamos uma AWS por
trás do sistema, podemos ficar sem região. Nesse contexto, não conseguiremos
fazer o deploy de todo nosso serviço.
Lembrando que não é incomum uma zona de disponibilidade ficar indisponível.

Por exemplo, digamos que temos a região Norte Virgínia e nessa existam
diversos datacenters que se comunicam rapidamente. Se um datacenter cair,
logicamente vamos tentar jogar nossos recursos computacionais para outro data-
center. Mas devemos pensar no que pode acontecer se não tivermos a quantidade
de IP’s necessários para isso. Acredite grandes empresas que trabalham com uma
enorme quantidade de máquinas podem sofrer com esse tipo de desafio. Ou seja,
até a divisão das subnets precisam prever esses tipos de adversidades.
Escalabilidade
Neste tópico, vamos pensar um pouco no poder que nossa aplicação consegue
escalar. Temos, basicamente, duas formas de escalabilidade: vertical e horizontal.
Vertical quando aumentamos os recursos computacionais da nossa máquina. E

horizontal quando adicionamos mais máquinas.
É necessário que possamos garantir que nosso sistema ficará o mínimo escalável
possível, principalmente de forma horizontal. Para isso é importante trabalhar
de forma stateless, bem como seguir boas práticas no processo desenvolvimento
como por exemplo o famoso “The Twelve-Factor App”.
Características Estruturais
No tópico anterior falamos um pouco sobre como fazer para que nossa aplicação
seja operada mais facilmente, isto é, sobre as características operacionais.
Neste tópico, falaremos sobre as características estruturais, que estão mais
relacionadas aos pontos de atenção que devemos ter no software para que este
funcione de forma cada vez mais flexível.
As características estruturais estão ligadas ao processo de desenvolvimento de

um sistema, ou seja, de como nossa aplicação será desenvolvida. E para facilitar
nossos estudos, dividimos essas características em aspectos que consideramos
essenciais para o conhecimento de todos que estão envolvidos no processo de

construção de um software. São eles: configurável, extensibilidade, fácil opera-
ção, reuso de componentes, internacionalização, fácil manutenção, portabilidade
e fácil suporte.
Configurável
Apesar de parecer algo simples, muitas aplicações são de difícil configuração.

Caso precisemos “setar” uma conexão com banco de dados, por exemplo,
teremos que decidir se colocaremos nosso código de uma forma hard coded ou
vamos trabalhar com variáveis de ambiente?
As respostas a esses questionamentos nos permite identificar se uma aplicação

é configurável ou não. Dizemos que a resposta será positiva se não precisarmos
fazer alterações no código fonte da solução para conseguir rodá-la em ambientes
diferentes.
Por exemplo, sobre formas de pagamentos. Se temos uma gateway de pagamento

como padrão, caso esta falhe é fácil fazer a alteração para uma outra?
Ao tentarmos subir uma solução, se precisarmos fazer uma só mudança do

código fonte para que esta possa rodar em diferentes ambientes, já perceberemos
que a aplicação não é configurável. Então, quando formos criar um software, por
padrão, é necessário que pensemos nisso para que nossa aplicação seja cada vez
mais configurável.
Extensibilidade
É fato que uma aplicação deve ser pensada para que consiga crescer. Ou seja, ela
precisa crescer de certo modo que as coisas possam ser “plugadas” nela.
Por exemplo, vamos imaginar que iremos utilizar a gateway de pagamento “X”
em nossa solução. Faremos, logicamente, a implementação dessa gateway em
nosso sistema. Porém, imaginemos que nosso superior solicite, posteriormente,
que façamos uma mudança para gateway “Y”. Agora, obviamente precisaremos
fazer uma nova implementação. Mas caso, durante essa nova implementação,
precisemos mudar pontos estruturais de nossa aplicação para conseguir adicio-
nar a nova gateway, é bem provável que tenhamos projetado nosso sistema de
maneira errada.
Precisamos conseguir trabalhar com interfaces, adaptadores etc. para que possa-
mos simplesmente adicionar coisas a nossa aplicação, de modo que não fiquemos
reféns dos vendors que trabalhamos.
Nesse contexto, podemos falar sobre conceitos como o de camadas de anticorrup-

ção, em que conseguimos separar nossa aplicação em camadas finas com mundo
externo. Então, se precisarmos trocar de bancos de dados ou o Message Brocker,
podemos apenas adicionar novos módulos, sem precisar mudar a base do que
estamos criando.
Assim, nossa aplicação precisa ser extensível tanto nos lados de vendors, que vão
ser plugados, como também ao ponto de conseguirmos adicionar novos módulos

nela. Caso seja difícil adicionar novos módulos, se precisarmos refatorar muita
coisa sempre que tentarmos adicionar algo em nossa solução, é muito provável
que precisemos rever essa estruturação.
Fácil instalação
Se todas as vezes que formos fazer o deploy, criar um ambiente de testes, um

ambiente staging, um de produção ou criar um ambiente na máquina de algum
companheiro de trabalho e isso for algo extremamente demorado, sabemos que
poderá dificultar o nosso trabalho. Por esse motivo nossa aplicação precisa ser
de fácil instalação.
Mas quais são os principais problemas que enfrentaremos para fazer a instalação
de uma solução?
Em primeiro lugar, como dificuldade de instalação, temos a padronização do

ambiente. No contexto atual, para que possamos padronizar um ambiente no
qual sua aplicação vai rodar, a melhor alternativa é trabalhar com containers,
Docker, etc, vai garantir que sua aplicação trabalhe até com o mesmo kernel que
você escolheu na imagem.
Em segundo lugar, voltaremos a falar que a aplicação precisa ser de fato confi-
gurável, isto é, se for muito muito difícil de configurar seu sistema, obviamente,
será dificultoso fazer a instalação.
Outro ponto que podemos abordar é que muitas vezes a aplicação tem depen-
dências que são extremamente complexas para se trabalhar. Um exemplo disso
é quando o sistema vai trabalhar com Elasticsearch, que é algo extremamente
complexo, principalmente em nível de infraestrutura. Nesse caso, podemos pen-
sar em alguns questionamentos: Como fazer para testar isso? Podemos trabalhar
com docker e com Elasticsearch? Quando formos trabalhar em produção, como
trabalhar com processos de configuração e conexão? Como vai ser a criação dos
índices? Serão criados pela aplicação ou manualmente no servidor de produção?
Podemos pensar também sobre tópicos do Kafka. Precisamos ter em mente se

nossa solução irá criar um tópico ou se esse tópico já vai vir criado.
Ainda sobre essa reflexão podemos nos lembrar do RabbitMQ e a criação de filas,
criaremos a fila ou esta já vai vir?
Esses tipos de coisas são extremamente importantes quando pensamos em fazer

uma instalação, principalmente se dependermos de itens de terceiros, inclusive
banco de dados.
Reuso de componentes
Usar componentes para facilitar nosso dia a dia, pode mudar completamente
a forma como iremos trabalhar. Porém devemos levar em consideração que
existem alguns aspectos que não são tão simples de lidar.
Vamos imaginar, por exemplo, que temos um sistema monolítico. Sabemos

que uma grande vantagem desse sistema é que não existe latência de rede,
isto é, não temos problemas de conexão, pois tudo está dentro de um mesmo
sistema. E uma vez que estamos dentro de um mesmo sistema podemos ter
frameworks e boas bibliotecas para facilitar nosso trabalho. Quando temos um
mundo um pouco mais distribuído, com microsserviços e diversos sistemas,
muitas vezes as equipes acabam criando soluções iguais para resolver o mesmo
problema. Ou seja, digamos que a equipe “A” crie uma biblioteca de validação
e a equipe “B” crie outra biblioteca de validação; eventualmente o que poderá
acontecer é que teremos duas coisas para serem mantidas. Então, nesse momento
poderíamos pensar na possibilidade de ter uma vertical dentro da empresa, onde
adicionaremos todas as todas as bibliotecas que podem ser compartilhadas e
criaremos times paralelos para manter essas bibliotecas, assim todos podem
utilizá-las.
Internacionalização
Esse aspecto não é visto com tanta frequência no Brasil, pois não é comum que
precisemos internacionalizar nossos softwares. Obviamente, pode surgir esse
tipo de trabalho e, por isso, é importante que saibamos minimamente como
desenvolver nossa solução possibilitando sua internacionalização.
Inicialmente, é importante termos em mente que a maior dificuldade desse

aspecto não fica no Backend. Já que o Backend possui muitos frameworks,
isto é, muitas formas maduras para trabalharmos com internacionalização. A
maior dificuldade pode ser outra. Por exemplo, na área do Frontend podemos
desenhar um layout de certa forma, mas quando precisarmos trocar a linguagem
do sistema, este poderá ficar totalmente desconfigurado e consequentemente as
coisas não irão funcionar do modo que planejamos. Outra situação, é o fato
da cultura de quem passará a usar, após internacionalização, ser totalmente
diferente. Estes aspectos dificultam o manuseio do software principalmente pela
tradução.
Ao criarmos um projeto, precisamos refletir se em algum momento este precisará

se internacionalizar. Precisamos pensar quais pontos serão impactados direta-
mente nesse processo. Por exemplo, se vamos trabalhar com moedas, qual será a
moeda base? Se for o real, o que acontecerá quando mudarmos para o dólar?
Nesse caso, provavelmente mudaremos a gateway de pagamento. Podemos
trabalhar então com a Paypal, pois esta empresa trabalha com transações
internacionais. Outro ponto é pensar em como vai funcionar o processo de
conversão. Caso não dê para parcelar, como vai funcionar a cobrança recorrente?
Como será a política de definição de preço? O software vai fazer a conversão de
forma automática ou teremos um local do sistema onde o administrador, em
algum momento, vai setar o valor de cada moeda?
Então, podemos perceber que esse aspecto é extenso e demandaria muito tempo
para abordarmos de forma mais detalhada. Porém, o que podemos destacar é
que sempre que criarmos uma aplicação é importante pensarmos se existe a
possibilidade de internacionalização. Caso a resposta seja sim, devemos começar
a levantar as principais possibilidades de falhas na solução ao precisarmos

internacionalizar-lá.
Portabilidade
Para compreendermos a portabilidade, falaremos um pouco sobre mudanças no

banco de dados. Nessa situação, surge o questionamento: é possível alterar o
banco de dados sem impactar de uma forma muito grande o código da sua
aplicação?
A verdade é que nunca vai ser tranquilo mudar o banco de dados sem impactar
nossa solução. Mas podemos dizer que, tecnicamente, é possível mudar o banco
de dados sem impactar de uma forma muito significativa o código de nossa
solução. Por exemplo, se estivermos trabalhando com Elastic Stack e precisarmos
mudar para New Relic ou para Datadog, devemos pensar se esta mudança será
fácil para nosso sistema.
Outro questionamento, é se vale a pena trabalhar com open telemetry. Será que
poderá facilitar nosso trabalho com vendors? Além disso, saber se está fácil
mudar um gateway de pagamento também ajuda a pensar em portabilidade.
Assim, pensando na portabilidade, podemos fazer com que os sistemas fiquem
menos dependentes dos vendors.
Fácil suporte (logs e debugging)
É muito importante que consigamos entender onde estão acontecendo os pro-

blemas, caso eles aconteçam, em nossa solução. Precisamos que, no momento
em que nossa aplicação estiver em operação, fique fácil entender exatamente
o que está acontecendo para que seja possível solucionarmos as adversidades.
Isso significa suportar a aplicação. E o suporte do sistema não é somente o call
center. O suporte é realmente garantir que nosso software está rodando de forma
aceitável e que conseguiremos ver rapidamente se está acontecendo alguma
dificuldade, antes mesmo de nosso cliente ligar falando sobre a situação. Nesse
ponto, precisamos pensar em como logar e em como conseguir criar diversas
formas para “debugar”. Além disso, trabalhar com observabilidade e centralizar
logs, criar métricas; tudo isso faz parte da observabilidade.
Diante de tudo isso, podemos trazer algumas dicas: primeiro, foque em obser-
vabilidade e em padrão de geração de logs. Cada framework tem um padrão de
logs, logo, é extremamente importante que tentemos consolidar os nossos logs
em um único padrão e, dessa maneira, ficará muito mais fácil todo processo de
operação.
Características Cross-Cutting
As características de Cross-cutting são aspectos que irão cruzar a aplicação de

forma geral, ou seja, são coisas que precisamos sempre levar em consideração
no dia a dia. Lembrando que pensar nos aspectos de uma solução de modo
intencional traz, de todo modo, “sorte” ao desenvolvedor.
Acessibilidade
Precisamos estar cientes de que nossa aplicação poderá ser acessada por um
grupo diversificado de pessoas, com necessidades de acessibilidade distintas.
Normalmente, quando falamos nesse aspecto acabamos mantendo nosso foco

mais no Frontend. Isso acontece pois existem bibliotecas que podem nos ajudar a
contornar muitas das complexidades técnicas no momento em que pretendemos
deixar nossa solução mais acessível para que leitores de tela possam trabalhar.
Nesse contexto, mesmo havendo diversos padrões que podem nos ajudar, deve-
mos focar sempre em um ponto: outras pessoas conseguem acessar facilmente
nossa plataforma, isto é, pessoas com comorbidades, deficiência visual ou
auditiva e etc. conseguem ter acesso a nossa aplicação?
Existe um movimento muito grande em torno da acessibilidade, e é muito

importante adotarmos boas práticas quando formos desenvolver uma solução.
Processo de retenção e recuperação de dados
Ao construirmos um software, é importante termos em mente que os dados não

devem ser ignorados. Podemos pensar que nossos storages são caros, e existem
diversas formas de trabalharmos retenção de dados. Por exemplo, se estamos
trabalhando com um sistema de stream de dados como o kafka, cada tópico
que criamos, podemos especificar que aqueles dados ficarão disponíveis por
um período de tempo predeterminado (por 7 dias, por exemplo). E depois desse
período esses dados serão apagados.
Então se nos questionarmos sobre o que temos de dados hoje, realmente esses
precisam existir a longo prazo? Caso a resposta seja positiva, como poderíamos
guardar esses dados? E como mantê-los?
Hoje em dia, existem técnicas muito interessantes para trabalharmos com dados.
Por exemplo, o que poderíamos fazer em caso de dados que precisamos com
frequência? Esses dados, mais conhecidos como dados quentes, estarão ali
em nosso banco de dados. Conforme tudo está rodando, vamos acessando e
consultando essas informações. Já dados menos acessados, ou seja, dados frios,
podem ser armazenados em um outro tipo de storage com um menor custo.
Autenticação e autorização
De um modo geral este tema parece algo simples, porém, se trabalhamos com
arquitetura distribuída existem muitas formas possíveis de autenticar e autorizar
requisições. Por isso, de certo modo, torna-se algo mais complexo do que parece.
Por exemplo, ao trabalharmos com uma arquitetura distribuída normalmente

teremos um identity provider (ex: Keycloak).
Outro ponto que merece nossa atenção é a possibilidade de utilizarmos API Ga-
teway em nossa solução, um serviço que poderá fazer o processo de autenticação.
Existem muitas empresas hoje em dia em que o sistema não tem mais validação
de autenticação, justamente porque a autenticação acontece na API Gateway.
Devido a isso sabemos que o usuário que está chegando naquele sistema já
passou por uma autenticação.
Neste ponto, é importante conceituarmos API Gateway, para que possamos

prosseguir em nossos estudos. Podemos dizer, resumidamente, que API Gateway
é um mecanismo que fica mais na borda de nossa aplicação e quando os usuários
acessam a solução caem primeiramente nessa borda. Nesse mecanismo é possível
ter políticas de autenticação, políticas de timeout, políticas de quantidade de
requisições etc. Ou seja, existem diversos plugins, de forma geral, que podemos
trabalhar em uma API Gateway.
Por outro lado, quando trabalhamos com sistemas monolíticos esse processo
de autenticação e autorização do usuário é algo mais simples. Pois é possível
encontrarmos diversos frameworks que nos ajudarão a resolver desafios dessa
natureza. Quando estamos no mundo distribuído isso realmente será um pouco
mais complexo. Nesse segundo caso, é sempre importante pensarmos em um
servidor de identidade que nos ajude nestes aspectos.
Então, é importante pensarmos se vale a pena implementar autenticação em

nossos microsserviços ou se o ideal é trabalhar com algum mecanismo de
autenticação, que faça essa autenticação antes mesmo da requisição chegar em
nossos microsserviços.
Legal
Anteriormente, falamos em dados. Sobre a importância de pensar onde e o tempo

que nossos dados serão mantidos em nosso sistema.
É importante termos em mente, além disso, que tudo o que acontece em nossa
aplicação precisa estar em conformidade com as leis do país onde ela está
rodando, inclusive temas relacionados ao uso de dados. Isso deve ser pensado
em todas as aplicações que formos desenvolver. Mas normalmente quando
uma organização está muito ligada a esse ponto é comum que essa corporação
transfira esses aspectos para nós desenvolvedores.
Privacidade
Ao criarmos um software é essencial que pensemos na perspectiva da LGPD (Lei

Geral de Proteção de Dados Pessoais), para sabermos como minimizar problemas
em relação a possibilidade de vazamento de dados dos usuários. Existem alguns
pontos extremamente importantes que não podemos deixar de pensar e essa
é uma cultura que nós, enquanto desenvolvedores, devemos ter. Por exemplo,
quando vamos testar uma aplicação é muito mais fácil testar se tivermos uma
cópia do banco de dados em produção para validar as coisas. Neste momento, é
importante sabermos que quando precisarmos de uma forma a mais para validar
vazamento de dados, mesmo nomes e emails já são considerados dados.
Existem muitas “manobras” que as empresas estão fazendo para ajudar nessa
questão. Por exemplo, todos os dados sensíveis de usuários estão sendo separados
em outro banco de dados, ou seja, em outro nível de serviço; mas eventualmente
podem ficar criptografados. Assim, o sistema principal só roda com dados muito
básicos para que o usuário consiga carregar. A organização faz isso porque
quando separamos a base de dados, podemos mitigar os riscos de vazamento.
Essa manobra pode garantir a privacidade do usuário, em conformidade com as
leis vigentes.
Nos dias atuais, falar em privacidade é algo muito crítico na maioria das
organizações. É possível, e provável, que tenhamos clientes que nos façam
assinar diversos contratos sobre políticas de privacidade. Isso ocorre pois a
empresa responde legalmente pelos dados dos usuários.
Segurança
É essencial que a segurança de um sistema seja feita de “ponta a ponta”. Então,

podemos dizer que a primeira sugestão sobre esse aspecto é para pensarmos em
segurança desde a borda da aplicação, ou seja, bem antes do usuário acessar o
servidor. Além disso, é interessante que trabalhemos com web firewall. Vamos,
assim, criar regras e mecanismos que consigam identificar os robôs para ficar
batendo em nossa aplicação. Dessa maneira, com o uso de web firewall já
conseguiremos barrar tentativas de SQL injection, XSS e provavelmente as
principais tentativas de exploração que podem ser encontradas na OWASP.
Outra sugestão muito importante nesse aspecto é que devemos usar preferenci-
almente padrões abertos em nosso software. Por exemplo, não é interessante
tentarmos criar formas próprias de criptografia. Resumidamente, é melhor
evitarmos criar qualquer coisa que envolva segurança. Ao invés disso, é sempre
mais indicado que usemos um padrão aberto. Pois esses padrões foram criados
por pessoas que se dedicaram durante muitos anos a pesquisas e especializações
para criar boas práticas.
Outra prática que pode nos auxiliar é a de manter o backup em outras redes.
Usabilidade
É consenso entre a maioria dos devs que para usabilidade no Frontend existem
diversas ferramentas e profissionais que podem nos ajudar a entender um pouco
melhor a navegação do usuário. Existem ferramentas que mostram o usuário
navegando, isto é, conseguimos ver o seu comportamento. Mas quando falamos
em usabilidade, não podemos nos limitar ao Frontend.
Devemos pensar também no Backend. Assim, ao trabalharmos com API pre-

cisamos pensar: “Ela está organizada?”, “Como está organizada?”, “Tem do-
cumentação?”, “Como estamos documentando tudo?”, “É de fácil utilização?”,
“Estamos trabalhando com padrões OpenAPI?”, “Possuímos um contrato claro
da nossa API, que possa disponibilizar para outras pessoas?”, “Como estamos
documentando?”, “Temos um README?”.
Além de tudo isso, é necessário que nos perguntemos também: quem é nosso
cliente? Quem vai usar nossa aplicação? Vai ser outra aplicação? Como pode-
mos desenvolver de modo a facilitar o trabalho com nossa aplicação? Como
proporcionar a melhor experiência possível para o meu cliente?
Quem é de Frontend vai sim ter que pensar em muita coisa. Até dar nomes de
eventos para conseguirmos mapear e trackear os principais eventos, uma vez
que quando estamos trabalhando com algum APM (Application Performance
Monitoring) todas essas informações são armazenas e sem dúvidas vão nos
ajudar em eventuais comportamentos inesperados pelo lado do client.
Perspectivas para arquitetar software de

qualidade
Neste tópico, falaremos sobre algumas perspectivas que nós, como pessoas
desenvolvedoras, devemos ter para conseguirmos arquitetar um software de
qualidade. Nesse caso, nós podemos citar três perspectivas básicas que nos
ajudam a perceber se nosso software está mais propenso a ter sucesso quando
for ao ar.
Primeiramente vamos falar sobre a perspectiva relacionada à performance.

Compreenderemos o que significa ser performático. Além disso, veremos quais
métricas devemos usar para que consigamos ter performance em nossos sistemas
no dia a dia.
A segunda perspectiva é relacionada à escalabilidade. Precisamos saber o que

fazer para que o nosso software seja escalável, ou seja, para que ele consiga se
manter estável conforme o número de requisições cresce.
A terceira e última perspectiva é em relação à resiliência. Esse ponto é extre-

mamente importante para nós, porque sem isso não conseguiremos partir do
pressuposto que o nosso software vai falhar. Todo software nasceu para falhar;
nasceu para ter bugs e para ter problemas, inclusive onde nós não temos controle.
Performance
Este é um assunto que praticamente todas as pessoas desenvolvedoras gostam de

falar. Porém, existem algumas dificuldades presentes nesse tema: muitas vezes as
pessoas não conseguem medir e compreender o que realmente é a performance
de uma solução.
Antes de tudo, é importante termos bem claro o seu conceito. Performance é o

desempenho que um software possui para completar um determinado workload.
Conseguiremos, por meio desse aspecto, verificar o desempenho que o sistema

está tendo para desempenhar uma ação, que é o seu papel no dia a dia.
Partindo do princípio que sabemos disso, obviamente precisamos de dados para

conseguirmos avaliar a performance de nosso sistema. Lembrando sempre que
não iremos verificar o desempenho do nosso software o comparando com a do
“sistema vizinho”. Devemos comparar a performance da nossa solução com ela
mesma.
Métricas para medir a performance
Todas as vezes que quisermos avaliar um software, logicamente, teremos diver-

sos aspectos para olhar. Mas existem dois aspectos que devemos nos atentar
necessariamente, pois estes poderão definir realmente como analisar a perfor-
mance de uma solução.
Sendo assim, as principais unidades de medida para avaliarmos a performance
de um software são: latência e throughput.
A latência ou “response time” pode ser definida como o tempo de resposta

que vamos receber. Por exemplo, sempre que vamos fazer uma requisição, o
tempo até o software processar essa chamada e ele nos retornar o resultado é
considerado a latência. É mais comum ouvirmos o termo “response time”, mas
saiba que tem o mesmo significado que latência.
O segundo indicador que devemos utilizar é o throughput. Este nos mostra o

quanto de requisição nosso software consegue suportar. Mais adiante, falaremos

deste tópico com mais detalhes.
Antes de darmos continuidade, é importante termos em mente que ter um

software performático é diferente de ter um software escalável. Normalmente,
é comum misturarmos esses termos. Porém devemos ter claro que são aspectos
diferentes. Ou seja, podemos ter um sistema performático que não é escalável
ou vice-versa.
Como melhorar a performance do software
Para melhorarmos a performance do nosso software, o primeiro passo que

devemos seguir é diminuir a latência. Ou seja, o “response time” precisa ser
menor.
Precisamos ter em mente que nossa latência é afetada pelo tempo de proces-
samento da aplicação, rede e chamadas externas. Isso é algo extremamente
importante e não podemos deixar de levar em consideração. Por vezes ficamos
otimizando nossa aplicação, sem considerar o tempo da chamada que o usuário
faz até chegar em nossa aplicação. Quanto mais longe estiver do datacenter,
quanto pior for a rede, consequentemente pior será a performance da nossa
solução. Muitas vezes, nossa aplicação depende de chamadas externas para rodar.
Vamos imaginar que o usuário coloque um CEP para que possamos trazer o
seu endereço. Nessa situação, teremos que acessar a API dos Correios, mas
se essa API estiver muito lenta naquele momento, isso irá afetar diretamente
a performance do nosso sistema. Muitas vezes, pessoas desenvolvedoras não

conseguem perceber isso. Assim, o software pode até estar todo otimizado, mas
a chamada externa está aumentando muito o “response time”. Normalmente
isso acontece devido a falta de observabilidade para conseguir perceber que o
obstáculo está em uma chamada externa.
Outro ponto que merece nossa atenção, ao falarmos de como melhorar a

performance, é o aumento do throughput. Fazemos isso quando permitimos
que nosso software consiga lidar com mais requisições. Por exemplo, se o nosso
sistema está aguentando dez requisições simultaneamente, e conseguirmos fazer
com que ele receba vinte, trinta… cem requisições de modo simultâneo, com
certeza ele vai conseguir ser mais performático. Porque quanto mais requisições
ele aguentar e quanto mais rápido ele deve retornar para o usuário final, mais
performático nosso software vai ser.
O throughput de uma forma ou de outra está totalmente ligado à latência. Se

nosso “response time” está demorando, muito provavelmente está tendo uma
conexão presa em nossa aplicação. Quanto mais requisições estiverem presas
em nosso software, raramente nossa aplicação vai conseguir lidar com mais
conexões ao mesmo tempo, diminuindo assim o throughput.
Além disso, é essencial observarmos que se nossa aplicação não for boa, isto é,
não for bem feita, ela também deixará de ser performática.
Principais razões para baixa performance
Se não soubermos para onde olhar, podemos acabar arriscando nas tentativas
e erros para realizar o aumento da performance em nosso sistema. Neste
tópico, queremos mostrar “o caminho das pedras” para que você saiba um
pouco mais sobre os pontos onde normalmente podemos encontrar dificuldades
em aumentar a performance, isto é, as principais possíveis razões para que a
performance de uma solução esteja baixa.
Primeiramente, é necessário que falemos sobre o processamento ineficiente.

Normalmente quando temos um sistema que está trabalhando de modo muito
ineficiente, é bem possível que seus próprios algoritmos podem estar causando
tais problemas.
Outro ponto importante a ser abordado é sobre recursos computacionais. É

provável que se estivermos rodando em um hardware ruim, nossa performance
seja menor. Então, podemos pensar no seguinte trade-off: Quanto maior nosso
hardware, maior será nosso custo. Por outro lado, quanto menor for nosso hard-
ware, menor será nosso custo, porém, menor será também nossa performance.
Quando começarmos a falar sobre escalabilidade, veremos que precisamos
conseguir alinhar esse aspecto pois, eventualmente, precisaremos adicionar mais
poder computacional ao nosso sistema (mais adiante veremos duas formas de
fazer isso).
O próximo ponto que iremos observar é algo que está, muitas vezes, totalmente
visível para os devs. Porém, algumas vezes pode não ser tão perceptível. Estamos
falando sobre trabalhar de forma bloqueante. Ainda é muito comum nos dias
de hoje ver linguagens de e abordagens de desenvolvimento que trabalham
essencialmente de forma bloqueante, gerando claramente uma barreira para
aumentar o throughput da aplicação.
Principais formas para aumentar a eficiência
Reconhecer situações que diminuam a performance da nossa aplicação é algo

essencial para nós desenvolvedores. Sabendo como evitá-las, possivelmente
conseguiremos aumentar a eficiência do nosso software.
Quando escalamos a capacidade computacional do nosso software, conseguimos

perceber qual, e onde, é a “dor” que estamos enfrentando em determinado
momento. Por exemplo, se o problema maior estiver na CPU especificamente,
significa que o poder de processamento está gerando uma baixa performance.
O disco também pode trazer dificuldades para aumentar a eficiência da nossa

aplicação. Caso seja necessário fazer muito I/O (input/output) em nossa apli-
cação, é provável que o disco esteja muito lento. Possivelmente, caso nosso
acesso seja muito grande, nossa própria rede poderá não permitir a chegada de
todas as requisições em nossa aplicação. Acredite, isso é muito comum quando
trabalhamos com cloud. Dependendo do tipo de máquina que usarmos, veremos
que a largura de banda muda completamente.
É essencial lembrarmos que não existe mágica no processo de construção de

um software. Para melhorarmos de fato nossa eficiência, precisamos pensar na
lógica por trás do software. Assim, é importante aperfeiçoarmos nosso algoritmo,
nossas querys e o overhead dos frameworks.
Nós, como devs, temos que conseguir analisar cada um desses tópicos individual-
mente para sabermos onde está o problema. Não adiantaria fazermos o algoritmo
mais performático, se a todo momento estamos fazendo I/O com um disco lento.
Para aumentar a eficiência do nosso software, podemos pensar um pouco sobre

o acesso serial. É importante utilizarmos uma linguagem de programação que
nos permita trabalhar com concorrência ou paralelismo. Isso, basicamente, vai
nos permitir lidar com diversas coisas ao mesmo tempo, isto é, fazer coisas
de formas diferentes, porém em conjunto. Precisamos muito disso nos dias de
hoje, principalmente quando necessitarmos ter muita performance. A linguagem
GO pode ser um bom exemplo. Para cada acesso em um webserver Go, uma
nova thread é criada, então nesse momento é possível processarmos de forma
simultânea diversas requisições, aumentando assim o throughput.
Grande parte dos softwares são otimizados e passam por diversos procedimentos
durante seu desenvolvimento. Mas o obstáculo, na maioria das vezes, está no
banco de dados. É importante que saibamos como modelar e usar banco de
dados do modo de forma correta. Além disso, precisamos utilizar estratégias para
buscarmos por performance intencionalmente. Por exemplo, pensar se o nosso
banco de dados está com índice, fazer um “explain” em nossas querys para ver o
tempo de execução. Fora isso, precisamos ter ferramentas de APM que realmente
nos mostram, no banco de dados, se nossa query está comprometendo a nossa
aplicação.
Outro ponto importante é o uso de caching. É essencial sabermos que isso tem
se tornado cada vez menos opcional se quisermos ter alta performance. Muitas
vezes, durante o processo de desenvolvimento de uma solução, processamos algo
apenas uma única vez e quando precisamos fazer a mesma consulta no banco de
dados, ou processar o mesmo template, ou fazer o mesmo algoritmo é possível
perceber que a resposta está pronta em um cache. Ele pode estar no disco ou na
memória, porém, em um servidor separado de nossa aplicação.
Essas informações podem nos ajudar a desenvolver um software de qualidade,

isto é, um sistema altamente performático. Por isso, é crucial que tenhamos
familiaridade com esses aspectos. Além disso, devemos ter a boa prática de
pensar neles de modo intencional durante todo o processo de desenvolvimento
da nossa solução.
Capacidade computacional: Escala vertical vs

horizontal
É comum precisarmos aumentar a capacidade computacional do nosso sistema

para suportar mais requisições, ou seja, realizar o processo de escala vertical.
Por outro lado, temos a opção de escalar nossos sistemas de forma horizontal,
onde aumentamos também a capacidade computacional, porém, nesse caso, no

número de máquinas.
Logo, podemos perceber que performance tem uma relação direta com escalabi-
lidade. Pois a escalabilidade tem um ponto muito claro em relação a aumentar
os recursos computacionais, fazendo assim com que a performance do sistema
de forma geral seja ampliada.
Diferença entre concorrência e paralelismo
Podemos usar uma citação de Rob Pike para diferenciar esses dois termos:
“Concorrência é sobre lidar com muitas coisas ao mesmo tempo. Paralelismo é
fazer muitas coisas ao mesmo tempo”.
Além dessa citação, alguns exemplos práticos podem nos ajudar a compreender
o que é concorrência e paralelismo. Imagine que estamos mexendo no teclado de
nosso computador, depois passamos a organizar nosso microfone e em seguida
falamos com alguém, logo em seguida, após a ligação, ajustamos o teclado e
depois o microfone novamente. Podemos perceber, nesta situação, que estamos
realizando diversas tarefas, ou seja, um pouquinho por vez, mas diversas tarefas.
Isso é denominado como concorrência.
Por outro lado, se estivéssemos gravando um vídeo e falando ao telefone ao

mesmo tempo, isto é, fazendo atividades ao mesmo tempo, dizemos que se trata
de paralelismo, ou seja, realizar tarefas de forma simultânea.
Exemplo: Vamos imaginar um Webserver
Vamos imaginar que temos um webserver e este tem um worker que trabalha
da seguinte forma: recebe cinco requisições, e cada requisição demora 10ms de
“response time”. Então, se tivermos cinco requisições, demoraremos 50ms para
conseguir realizar a tarefa. Nesta situação, temos um acesso serial. Podemos
considerar esse processo bloqueante. Pois fará cada ação de uma vez, isto é, cinco
requisições de forma serial.
Seria interessante se pudéssemos trabalhar esta mesma situação de forma

concorrente ou paralela. Podemos ter cinco threads, ou seja, cinco fios de proces-
samento. Isso significa dizer que teríamos um processo que conseguiria trabalhar
essas cinco requisições em conjunto. Podemos atender as cinco requisições em
10ms, pois teremos cinco threads trabalhando de forma paralela.
Isso tudo faz muita diferença. E é importante sabermos que é extremamente

comum que isso aconteça em webservers. Por exemplo, o Apache ao ser iniciado
temos uma configuração de quantos workers iremos trabalhar. Vamos imaginar
que ele tem cinco workers, isso quer dizer que ele só vai poder executar ali de
forma paralela cinco requisições ao mesmo tempo. Se temos cinco requisições
e nosso programa funciona de uma forma totalmente bloqueante, as outras
requisições que forem chegando irão se sobrepor até que saia uma e a outra
comece a chegar.
Logo, precisamos pensar em como aumentar essa quantidade de threads. Para

isso, podemos aumentar a quantidade de workers. O grande ponto é que para

cada nova thread que chamamos em nosso sistema operacional, gastamos 1
mega. Então, se começarmos gastando 1 mega, somente para liberar uma thread,
além da memória adicional utilizada para realizar a requisição, isso pode ser
insustentável, fazendo realmente com que os recursos do servidor se esgotem
rapidamente.
Se utilizarmos a linguagem Go, por exemplo, esse processo é feito de modo

diferente. Essa linguagem abre realmente uma thread para cada chamada no
webserver. Por isso ela consegue lidar com várias ao mesmo tempo. Por outro
lado, ela trabalha com um esquema chamado de green threads, que é uma
thread gerenciada pelo próprio runtime da linguagem e que ao invés de custar
um mega, custa 2k. Então, ela consegue lidar com muito mais requisições ao
mesmo tempo.
De uma forma ou de outra, sempre é importante tentarmos responder o máximo

possível de requisições, de uma forma não bloqueante. Para isso, precisamos
trabalhar pelo menos de modo concorrente (por esse motivo o node.js e a Sol
PHP tem sucesso).
Cache
O cache nos possibilita acessar itens (arquivos, imagens, etc) que já foram
processados e utilizá-los para trazer respostas, de maneira mais rápida, ao
usuário final.
Existe um tipo de cache chamado de “cache na borda”. Este fará com que
o usuário não precise bater nem mesmo em nosso cloud provider. Para isso
trabalhamos com algo chamado de Edge Computing. Quando usamos o Edge
Computing, o usuário não bate em nossa máquina, isto é, em nosso kubernetes,
etc; porque ele nos trará um cache totalmente processado na borda ou seja, em
um servidor que fica antes do seu servidor principal.
A plataforma Full Cycle, por exemplo, trabalha com Edge Computing. Isso
significa que trabalhamos com cache de toda nossa plataforma fazendo com que
usuário que acessar nossa nosso frontend, antes mesmo de a requisição bater
em nosso kubernetes, vai bater no serviço CloudFlare Worker. Desse modo, o
browser do usuário fará o download de todo HTML, CSS, Javascript, imagens,
etc, do local mais próximo ao usuário; com isso existe a real possibilidade de que
os arquivos estejam sendo baixados de uma central telefônica do seu próprio
bairro, por exemplo.
Para compreendermos melhor como funciona, é importante falarmos um pouco

sobre os dados estáticos. É muito comum que queiramos cachear esses dados
na borda. Podemos cachear imagens, css e outras coisas semelhantes a essas,
pois, fazendo desse modo, não precisaremos servir esses tipos de coisas o tempo
inteiro. Se não fizermos isso, a pessoa vai bater em nosso kubernetes e em nosso
servidor web. Então, cachear é algo extremamente barato e fará com que o
usuário tenha uma experiência melhor. Podemos pensar em algumas formas
extremamente efetivas para fazermos isso.
Existem muitos tipos de páginas que conseguimos cachear. Um exemplo é

exatamente um dos tipos de cache que citamos anteriormente: o HTML, que
pode ser cacheado na borda, o usuário somente acessa e pronto. Existem, ainda,
alguns caches que conseguem processar toda aquela home do nosso site, da
página de contatos até a parte de notícia. Podemos colocar um cache de 5
minutos, assim, todas as vezes que o usuário acessar nosso site, ao invés de
processar várias coisas do background, nós já lançamos o HTML e pronto.
Não gastamos todo um processamento, pois não bateu no banco de dados,
simplesmente devolvemos uma página web.
Vamos imaginar que temos um algoritmo pesado. Esse algoritmo tem muitas
variáveis que mudam a cada meia hora. Se todas as vezes que o usuário fizer
uma requisição que vai chamar esse algoritmo nós precisarmos processá-lo do
zero, será algo extremamente custoso. Então, para evitar isso, podemos cachear
esse resultado pronto a cada meia hora.
Outro tipo de cache é o de objetos. Existem objetos que nossa solução terá
que criar o tempo inteiro para gerar processamento de alguma forma. Aqui
na Full Cycle nós temos um sistema de ORM que é chamado de Doctrine. Ele
mapeia classes com a estrutura de banco de dados e, baseado nisso, conseguimos
trabalhar com modelo de persistência. O problema é que a todo momento ele
precisa fazer essa correlação entre o ID da classe e o ID da tabela do banco
de dados. Esse parsing tem um custo e, por esse motivo, podemos cachear o
objeto que tem toda essa relação com banco de dados, pois a estrutura não muda
com frequência. Isso quer dizer que sempre que formos trabalhar com o ORM,
podemos evitar esse tipo de processamento.
É importante sabermos que os caches podem trabalhar de forma exclusiva ou

compartilhada, e aqui vamos conhecer um pouco esses dois tipos de trabalho. É
essencial termos esses conceitos claros para sabermos as diferenças entre esses
dois modos.
Quando trabalhamos com cache exclusivo, geralmente será de forma local,

em uma máquina específica, o que poderá resultar em baixa latência. Isso
acontece pois tudo será processado localmente. Por exemplo: vamos imaginar
que temos duas máquinas iguais chamadas de “A” e “B”, e os dois sistemas
usam o Doctrine. Obviamente teremos uma baixíssima latência, mas o cache
será exclusivo em cada máquina, outras máquinas não podem se beneficiar
dele. Veja que com a duplicação conseguimos trabalhar com baixa latência. Por
outro lado, poderemos ter problemas quando precisarmos trabalhar por sessão.
Vamos pensar o seguinte: considerando que eu, Wesley, sou um usuário, e ao
acessar um servidor fiz login, no momento que fiz isso os meus dados ficaram
cacheados. Desse modo, não será necessário processar todas as informações a
todo momento, pois teremos tudo naquele cache. Nessa situação, imaginemos
que até a página home está personalizada com meu nome. Se eu acessar outra
máquina que tenha meu software duplicado, esta sessão, por ser local, estará
na máquina “A”, porém, não existirá na máquina “B”. Quando eu fizer o login,
precisarei cachear tudo novamente. Caso exista uma máquina “C”, terei que
fazer o mesmo processo para cachear os dados. Sempre que precisarmos ter
uma sessão de usuário, teremos que repetir esse processo, o que provavelmente
nos prejudicará. Quando precisarmos que o resultado final para o usuário seja
personalizado, se isso estiver espalhado em diversas máquinas, teremos esse tipo
de problema.
Por outro lado, temos algo que chamamos de cache compartilhado. Este cache
tem uma latência maior, pois trabalha com uma espécie de cache central. Ou
seja, os dados estarão centralizados para o uso de todos que precisarem. Mas,
por estarem centralizados, haverá uma latência maior. Para chegarmos nesse
servidor de cache, apesar de ter uma latência maior, não há duplicação do
cache. Vamos imaginar que temos duas máquinas chamadas de “1” e “2”. Pela
máquina “1” acessamos um portal e a home deste site é cacheada. Quando
acessarmos a máquina “2”, esta ainda não estará cacheada. Então, precisaremos
cachear novamente essa home. Tivemos, assim, que fazer o cacheamento duas
vezes. Se tivermos o cache compartilhado para 100 máquinas, essas 100 não
precisarão gerar cache novamente, pois o cache já estará compartilhado entre
todas. Nesse caso, percebemos a possibilidade de ter maior latência, porque
precisamos fazer uma consulta externa, porém conseguimos utilizar esse cache
em muitas máquinas. Essa é a grande vantagem: não há duplicação do cache.
Poderemos, assim, compartilhar sessões, pois sempre que o usuário fizer login,
os dados dele estarão no servidor de cache. Então, não importa qual máquina
for acessar.
Ao trabalharmos com cache compartilhado, temos um banco de dados de forma

externa, ou seja, todos acessam o mesmo banco de dados. E neste, podemos
cachear os dados até ele. Podemos ter um cache com resultado dessas consultas
em um Redis por exemplo. Esses dados ficam em memória, então temos um
cache extremamente rápido.
Cache: Edge computing
Neste tópico veremos, por meio de alguns exemplos práticos, como o Edge
Computing pode nos ajudar em relação ao cache.
A “falta” do Edge Computing nos próximos anos pode fazer com que a internet
não funcione tão bem quanto esperado, por isso ele está em evidência nos dias
atuais e a cada dia se fala mais sobre essa solução.
A Netflix pode ser um bom exemplo para que possamos compreender como
o Edge funciona. Imaginemos a quantidade de acessos que a plataforma tem
diariamente e a quantidade de tráfego que esses acessos geram. Se esses dados
estivessem em um datacenter nos Estados Unidos e os seus usuários estivessem
no Brasil, consequentemente seria necessário que o dado saísse dos EUA para
bater no Brasil. Isso, provavelmente, faria a rede de internet congestionar,
pois simplesmente teríamos uma sobrecarga em todas as máquinas da Netflix
para conseguir movimentar esses terabytes de dados. Como resultado, essa
sobrecarga se estenderia à internet de forma geral.
O Edge pode nos ajudar fazendo com que a informação do usuário esteja
mais perto. Assim evitamos que a sua requisição trafegue mais tempo pela
internet. Fora isso, ele consegue fornecer serviços, além de simplesmente uma
CDN (Content Delivery Network), que processam informações mais próximas
possível do usuário, evitando assim que ele bata em nosso servidor.
Lembrando que a internet não é ilimitada, isto é, a rede não é ilimitada. Quanto
mais pudermos evitar que o usuário fique longe da informação, será melhor em
diversos sentidos, tanto para a rede, quanto para o próprio usuário.
Normalmente, arquivos estáticos podem ser colocados imediatamente no Edge

por ser algo simples e barato. Em alguns casos pode ser inclusive gratuito
como na CloudFlare - em até determinado limite. É importante destacar que
não se trata de uma propaganda, mas sim de exemplos práticos utilizados na
própria Full Cycle. Utilizamos Cloudflare para diversos serviços como: arquivos
estáticos, CSS, imagens, HTML, etc.
Utilizando ainda o exemplo da Netflix, temos algo chamado de CDN (Content

Delivery Network). Nesse sistema é criado uma malha de servidores espalhados
no mundo. Quando nós, como usuários, subimos um vídeo da plataforma, o
pegamos de um datacenter mais próximo possível.
Hoje, trabalhamos com CDN na Full Cycle. E, mais uma vez, para exemplo
de algo que realmente utilizamos, podemos citar uma empresa que nos oferece
esses serviços: a Akamai. Ela é uma das maiores empresas que trabalham com
Edge Computing. Para termos uma ideia, a Akamai possui mais de 500 pontos
espalhados por todo Brasil. Então, inicialmente subimos nossos vídeos em um

Bucket da Amazon S3 na Virgínia. Quando o usuário acessa esses vídeos pela
primeira vez, a Akamai faz o processo de baixar esse vídeo e o joga em uma
malha de servidores, baseado em contratos e parcerias com provedores de
internet brasileira. Assim, é muito comum que, caso você esteja em São Paulo,
seu vídeo esteja sendo baixado de um servidor de São Paulo mesmo. Se você
estivesse em Portugal, seria baixado de um servidor em Portugal do mesmo
modo. Dessa maneira, as coisas começam a funcionar de maneira mais fluída.
Logicamente, tudo tem um custo. Esse custo é dividido em duas partes: a

primeira é custo da CDN e o outro é o de “transfer out” da S3 (como é no nosso
caso).
Quanto maior o vídeo, quando mais longo e mais longe estiver, provavelmente
teremos que fazer download o tempo inteiro. Isso fará com que nossa latência
seja maior e a chance desse vídeo começar a travar em nosso computador,
consequentemente, será maior. Quanto mais próximo esse vídeo estiver, menor
vai ser a latência e teremos mais chances de conseguir baixar esse vídeo e gerar
um cache local em nosso computador e assisti-lo de uma forma muito mais
tranquila. A CDN permite isso. É um preço que precisamos pagar, mas que
facilitará muito a experiência que teremos com nossos usuários.
Cloudflare Workers
Cloudflare é uma plataforma de Edge computing que começou fazendo proxy

e cacheando informações de sites para carregamento mais rápido. Fora isso,
também possui gerenciamento de DNS.
Hoje em dia, além dela trazer diversos serviços - inclusive de WAF (Web
Application Firewall), também podemos encontrar na plataforma os Workers.
Este é um serviço que permite que façamos deploy de aplicações. Normalmente
essas aplicações são executadas em javascript. Eles conseguiram isolar cada
requisição em um “container” utilizando a Engine V8, que é a mesma usada
pelo Google Chrome e também no Node.js. Resumidamente, podemos dizer que
a Cloudflare conseguiu criar um mini container que consegue executar de uma
forma muito rápida as requisições de forma mais próxima do usuário.
A plataforma Full Cycle, atualmente, roda na Cloudflare Workers. Isso significa

que, quando um usuário acessa a plataforma, o conteúdo é baixado mais próximo
dele. Fazendo com que tudo rode de forma extremamente rápida, processando
somente o javascript que está sendo chamado e cacheado do computador dessa
pessoa. Toda vez que fazemos o deploy de uma nova versão, ela vai distribuí-
las para todos os seus datacenters espalhados pelo mundo. Assim, vamos gastar
menos banda na hora que chegar ao usuário final. Além disso, vale lembrar que
o preço é extremamente acessível na maioria das vezes.
Escalabilidade
Em seu livro, Elemar Jr. nos traz a definição de escalabilidade. Ele nos diz que:
“É a capacidade de sistemas suportarem o aumento (ou redução) dos workloads,
incrementando (ou reduzindo) o custo em menor ou igual proporção.” Ou seja,
dizer que um software é escalável significa que temos o “poder” de aumentar ou
diminuir o throughput, adicionando ou removendo a capacidade computacional.
É essencial termos essa definição bem clara, pois é muito comum que exista
uma mistura de conceitos, principalmente em relação a performance. Enquanto
performance tem o foco em reduzir a latência e aumentar o throughput; a es-
calabilidade visa termos a possibilidade de aumentar ou diminuir o throughput,
adicionando ou removendo a capacidade computacional.
Nesse sentido, é possível termos um software performático, diminuindo a

latência e aumentando o throughput. Mas isso não significa que teremos
necessariamente uma solução escalável. Assim, percebemos que apesar de existir
certa ligação entre ser escalável e ser performático, existem muitas diferenças.
Escalando software: vertical vs horizontal
Existem duas maneiras de escalar um software: podemos fazer isso de modo

vertical ou horizontal.
Quando aumentamos o poder computacional de uma máquina através de
seus os recursos computacionais como memória, CPU, disco, etc, temos o que
chamamos de escala vertical. Por outro lado, se aumentarmos esses recursos
através do aumento de máquinas em si, temos uma escala horizontal.
Por exemplo: ao invés de usarmos uma máquina de 64gb de ram, usamos quatro
máquinas de 16gb cada. Então, nesse exemplo, aumentamos as máquinas para
facilitar nosso dia a dia. Logicamente, será necessário colocar um proxy reverso
ou um load balancer para rotear as requisições feitas por essas máquinas.
Conforme aumentamos os recursos computacionais, seja de modo vertical ou

horizontal, teremos mais escalabilidade. Porém, é importante sabermos que
algumas dificuldades podem surgir se trabalharmos com escalabilidade vertical.
Isso porque a quantidade de limite em uma máquina poderá dificultar nosso
trabalho. Chegará um momento em que uma máquina não terá todo poder com-
putacional para resolver nossos problemas. Além disso, se eventualmente houver
uma queda do sistema, todo nosso sistema cairá, pois está tudo concentrado em
uma máquina. Em uma escala horizontal isso não acontece, porque teríamos
várias máquinas. E se uma cair, logicamente nem todas ficarão fora do ar. Isso
facilita a manutenção da solução no ar. Assim, hoje em dia, é mais comum que
trabalhemos com escala horizontal. Porém, perceberemos que para que isso seja
possível existem algumas práticas que teremos que fazer em nosso software.
Nos próximos tópicos, falaremos sobre os pontos que devemos observar para
garantir que tenhamos uma solução escalável horizontalmente.
Escalando software: descentralização
Vimos que, de certo modo, é impossível permanecer escalando uma solução ver-
ticalmente. Por isso, é necessário sabermos o que fazer para permitir que nossa
aplicação escale de modo horizontal. E, para que isto seja possível, precisamos ter
atenção em alguns pontos relacionados a descentralização de dados, de estrutura,
de arquitetura, etc. Pois o modo como nosso software foi desenvolvido afeta
diretamente se conseguiremos ou não escalar horizontalmente.
Precisamos desenvolver nosso software de modo que, caso precisemos escalá-lo,
possamos aumentar a quantidade de máquinas a qualquer momento. E, caso
precisemos desescalá-lo, possamos remover essas máquinas. Então podemos
perceber que as máquinas devem ser algo “descartável”, ou seja, não devemos ter
apego a uma máquina específica. Isso quer dizer que ela precisa ser facilmente
criada e removida sempre que for necessário e sem medo algum. Precisa ser algo
natural. Assim, devemos seguir alguns guidelines.
Primeiramente, precisamos partir do princípio de que nosso disco é efêmero. Isso

significa que tudo que salvamos em disco, na nossa máquina, tem que poder
ser apagado na hora sempre que for preciso. Como exemplo, vamos imaginar
o wordpress. Este é um sistema que administra blogs, páginas, etc. Sabendo
disso, pensemos na seguinte situação hipotética: criamos um artigo para um
blog e fizemos um upload de imagens. Depois disso, fizemos outros uploads
de vídeos, etc. Provavelmente, essas imagens ficaram salvas em nosso disco.
O problema, neste caso, é que se perdermos essa máquina, consequentemente

perderemos todas as imagens deste blog. Isso é algo muito complexo, pois não
teremos o poder de eliminar essa máquina quando quisermos. Além disso, se
criarmos outra máquina rodando o wordpress para balancear a carga, essas
imagens só estarão naquela primeira máquina, não estarão na segunda. Assim,
se o usuário cair na outra máquina pelo Load Balancer, essas imagens não vão
existir. Portanto, toda vez que subirmos nossa aplicação, precisamos partir do
princípio que tudo que está no disco poderá ser perdido. Isso nos traz, de fato,
uma mudança de paradigma. Podemos pensar, então, para que usar o disco? A
resposta é: para gravar arquivos temporários e que irão auxiliar qualquer tipo de
processamento. Mas de forma geral, é um disco efêmero. Uma solução possível
para esse caso do WordPress seria fazermos o upload das imagens em um bucket
da S3, por exemplo. Dessa maneira, todas as máquinas que acessem esse software
não olharão para o próprio disco, mas sim para o bucket.
Outro ponto fundamental para conseguirmos fazer escala de modo horizontal

é pensarmos no cache centralizado, ou seja, o cache não deve ficar em nossa
própria máquina. Podemos nos lembrar, neste momento, do cache exclusivo
e compartilhado. Neste caso, devemos ter um cache compartilhado. Então, se
vamos fazer um cache de uma consulta em um banco de dados, esse cache não
deverá mais ficar em nosso servidor. Ele deve ficar em um servidor externo,
específico para cache, onde todas as máquinas que precisarem dele poderão
acessá-lo. Lembrando que a ideia principal que devemos ter em mente é: tudo
que está em nossa máquina poderá ser descartado para que essa máquina possa
ser destruída ou criada a qualquer momento.
Quando falamos em cache, no tópico anterior, abordamos um pouco a neces-

sidade de se termos sessões centralizadas. O usuário não deve precisar fazer
todo login novamente sempre que cair em um servidor diferente. Mas isso só
é possível se as sessões estiverem centralizadas. Normalmente, fazemos isso
através de um servidor específico para armazenamento de cache. Relembramos
esse conceito, para afirmar que o nosso software deve ser efêmero, isto é, ele não
deve armazenar estado. Todo estado que existir em nossa aplicação deverá ficar
gravado de forma externa.
Então, podemos dizer que escalar um software significa descentralizar. Tirar

tudo o que está focando em uma única máquina e jogar para um servidor externo.
Fazendo assim, permitimos que essa máquina seja criada e removida sempre
que quisermos, sem perder informações. Tudo com um único objetivo: poder
aumentar nosso throughput.
Escalando banco de dados
Falar sobre banco de dados é sempre muito complexo, pois é algo que muitos
de nós desenvolvedores temos dificuldade em trabalhar. Muitas vezes exige que
tenhamos um arquiteto tecnológico - uma pessoa especialista que seja um DBA
para nos auxiliar em alguns aspectos mais técnicos. Neste tópico, abordaremos
o mínimo que precisamos saber sobre escala de banco de dados e alguns pontos
fundamentais que precisamos levar em consideração sobre esse tema.
Primeiramente, devemos aumentar nossos recursos computacionais, pois quanto

mais recursos temos, quanto mais disco, mais memória, mais CPU, consequen-
temente, mais escalamos. Porém, precisamos nos lembrar que escalar recursos
computacionais, normalmente, tem um limite.
Por conta disso, precisamos começar a fazer segregações em nossos bancos de
dados. Por exemplo: distribuir responsabilidades. Então, se um banco de dados
está tendo muita escrita e leitura, podemos criar um banco específico para
leitura e um para escrita. Isso ajudará muito a distribuir responsabilidades nesse
ambiente. Normalmente, quando precisamos ter gargalos com banco de dados,
começamos pensando em fazer coisas semelhantes a essa, isto é, começamos
fazendo essas segregações.
Fora isso, podemos pensar também em como escalar nossa solução de forma
horizontal desde seu início. Às vezes, a quantidade de leitura está tão grande
que necessitamos, desde o início, adicionar várias máquinas de leitura ou,
eventualmente, até mudar o formato do banco de dados. Começamos a trabalhar
com diversos shards por exemplo.
Hoje em dia temos diversas opções de bancos de dados, por isso vale muito a
pena compreendermos qual tipo de aplicação vamos trabalhar. Isso possibilitará
uma escolha adequada, permitindo que possamos trabalhar bastante com deter-
minado banco de dados. Por exemplo: um banco que nos possibilite relacionar e
fazer consultas muito pesadas para gerar relações, um outro que nos auxilie no
trabalho com grafos. Caso precise pegar dados que nos ajudem a evitar milhares
de consultas de muitos relacionamentos, temos o MongoDb para trabalharmos

com documentos. Mas, se o caso for a necessidade de muita escrita, poderíamos
pegar o Cassandra. De forma geral, é muito comum separarmos leitura e escrita
para começarmos a criar máquinas e fazer essa escala de forma horizontal.
Hoje em dia muitas pessoas estão trabalhando de forma serverless, isso significa
que elas estão trabalhando de modo que, basicamente, não se “preocupam” mais
com o lado de servidores. Isto é, deixam seu cloud provider trabalhar por conta
própria, porque esses sistemas, normalmente, trabalham e criam bancos de dados
específicos para escalar de uma forma muito mais tranquila. Assim, podemos ler
documentos, mas não nos preocupamos de modo geral. Vale dizer que, quando
falamos em não nos preocuparmos, estamos nos referindo a esses desafios que
são bem complicados de enfrentar. Lembrando também que serverless não
significa apenas a lambda functions da AWS.
Muitas pessoas iniciam essa escala de qualquer forma, assim, deixam de olhar os
principais gargalos. Para evitar isso, é importante termos uma APM (Application
Performance Monitoring, pois com isso conseguiremos entender todas as queries
que estão rodando. É comum ouvirmos que o banco de dados está lento, mas será
que a pessoa está trabalhando com índice da forma correta? Ou está com medo
do banco de dados ficar mais lento por causa do índice?
Fora isso, podemos começar a modificar alguns padrões na hora de desenvolver

nosso software. Existe um padrão muito comum chamado CQRS (Command
Query Responsibility Segregation) e, neste padrão, podemos separar o comando
que é uma intenção do usuário da query que é para fazer leitura de dados. Ou
seja, separa a leitura da escrita. Falamos um pouco sobre isso em um tópico
anteriormente.
Proxy Reverso
Ao longo dos nossos estudos sobre desenvolvimento de soluções, é importante

termos algumas informações sobre o Proxy Reverso. Isso porque este é um
recurso que eventualmente poderemos precisar.
O nome proxy, traduzido do inglês, significa ‘procurador’, isto é, uma pessoa

que pode falar em nosso nome. Por este significado podemos construir a ideia
de como o proxy “normal” funciona. Normalmente, as empresas que utilizam um
proxy têm vários usuários e, geralmente, essas pessoas precisam frequentemente
acessar diversos sites. O proxy poderá direcioná-la para os sites que elas desejam.
Além disso, o recurso possui um filtro contra sites maliciosos. Resumidamente,
ele pega a requisição e redireciona para o site que o usuário solicita.
Por outro lado, segundo o site da Cloudflare, proxy reverso é um servidor

que fica na frente dos servidores de web e encaminha as solicitações do
cliente (por exemplo, navegador web) para esses servidores. Ou seja, quando
tentamos acessar um site, iremos bater num proxy que terá regras. Este irá nos
encaminhar para um servidor que esteja configurado para conseguir responder
essa requisição. Assim, precisamos entender que o proxy reverso é um servidor
que fica na frente de todos os outros. Ele tem regras e por isso nos encaminha
corretamente para determinados servidores atrás dele. Por exemplo, vamos

imaginar que estamos acessando um site chamado “a.com.br”. Este site está atrás
de um proxy reverso. Então, quando o acessamos, o proxy reverso percebe isso e
nos direciona para o servidor 1, 2 ou 3. Caso tentemos acessar “b.com.br”, ele fará
outro direcionamento para o IP 2, 3 ou 4. Ou seja, ele vai fazer adequadamente os
roteamentos. O proxy recebe todas as requisições, lê os dados, e, baseado neles,
toma uma ação para redistribuir essas ações.
Existem, atualmente, três soluções em proxy reverso que podem ser consideradas
mais populares e por isso, vale a pena conhecermos. O Nginx, o HAProxy (HA =
High Availabillity) e o Traefik. Definitivamente, desses três, o mais conhecido é
o Nginx. Então é interessante que saibamos configurá-lo, assim, conseguiremos
dominar diversas ferramentas que são baseadas nele.
Introdução à resiliência
O conceito de resiliência pode nos ajudar a ter uma ideia inicial do que significa
desenvolver uma solução capaz de se adaptar em diversas situações do nosso
dia a dia. Podemos dizer que resiliência é um conjunto de estratégias adotadas
intencionalmente para a adaptação de um sistema quando uma falha ocorre.
Fora isso, existe uma frase popular que também nos ajuda a compreender melhor
o conceito do que significa ter uma aplicação resiliente: “ou você dobra, ou você
quebra”.
Quando estamos trabalhando em um software e acontece uma situação de erro,

podemos ter duas respostas: primeiro, ele pode simplesmente explodir uma
exception, danificando a requisição, ou ele pode perceber que tem algo errado
e ter uma estratégia, um plano “B”, para, ainda assim, atender a requisição do
cliente, mesmo que de modo parcial. Então, podemos dizer que resiliência é esse
poder que temos de nos adaptar quando algo inesperado acontece.
É importante sabermos que a resiliência precisa ser feita de modo intencional,

porque, se não for feita assim, não saberemos qual será o comportamento
da nossa aplicação quando algo der errado. E, hoje em dia, não podemos
desenvolver um software jogando culpa em terceiros pelos seus “bugs”. Por
exemplo, se precisamos acessar um CEP para finalizar a requisição, mas o site
está fora do ar, não é interessante que o usuário deixe de finalizar seu pedido
por não termos esse dado. Devemos pensar em uma solução para conseguirmos
criar um usuário mesmo que o site fornecedor do CEP não funcione. Além desse
exemplo, temos também o da gateway de pagamento. Se o site estiver fora do ar,
precisamos pensar em alternativas para não perder a venda pela falha nesse site,
que deveria processar o pagamento. Precisamos adaptar nosso software para que
ele consiga ter um plano “B”, um plano “C”, e até um plano “D” se for preciso,
pois podemos ter absoluta certeza que nosso software vai falhar; ou por nossa
culpa, que desenvolvemos errado, ou por culpa de soluções em volta dele, que
farão com que ele dê erro. É essencial pensarmos o quão resiliente ele vai estar
para entregar a melhor experiência possível ao cliente.
Assim, ter estratégias de resiliência nos possibilita minimizar os riscos de

perda de dados e transações importantes para o negócio. Então, é essencial
conhecermos algumas estratégias que nos possibilitem ter uma solução, de fato,
resiliente.
Proteger e ser protegido
Não devemos criar planos de solução de maneira aleatória. Precisamos ter

estratégias de resiliência que nos ajudem a resolver os problemas mais comuns
que possam surgir em nossa aplicação.
Quando falamos em resiliência, temos que pensar, primeiramente, em proteger e

ser protegidos. Isso porque, geralmente, nossa aplicação fará parte de um ecossis-
tema. Nos dias atuais, é muito comum trabalharmos com sistemas distribuídos;
por exemplo, os microsserviços, assim, temos vários sistemas que se comunicam
entre si. Por esse motivo é importante pensarmos em duas coisas: proteger nossa
aplicação e a do vizinho.
Um sistema em uma arquitetura distribuída precisa adotar mecanismos de

autopreservação para garantir ao máximo sua operação com qualidade. Vamos
imaginar que temos três sistemas… quando formos trabalhar com eles precisa-
mos ao máximo contribuir para que esse ecossistema esteja saudável, que todos,
mesmo aqueles sistemas que não fizemos, consigam operar da melhor maneira
possível, pois eles nos afetam. Ou seja, precisamos preservar os demais sistemas
para que quando precisarmos dele, ele nos responda. Mas, ao mesmo tempo,
temos que nos preservar para que quando eles precisem de nós consigamos
responder também.
Então podemos dizer que um sistema não pode ser egoísta a ponto de realizar
mais requisições em um outro sistema que está falhando. Se temos um sistema
“A” e precisamos de uma informação do sistema “B”, mas por algum motivo
ele demora a nos responder e, depois disso, precisamos fazer outra pergunta e
novamente ele demora, se ao invés de esperar um pouco mais, mandarmos a
pergunta por várias vezes seguidas, esse sistema provavelmente sairá do ar. A
consequência disso é que, com esse sistema fora do ar, todo ecossistema ficará
comprometido. Se estava difícil termos nossa resposta, agora ficou mais difícil
ainda. Por isso, um sistema não deve ser egoísta e enviar várias requisições segui-
das assim. Em relação a tudo isso, o que queremos destacar aqui é a importância
de existir harmonia entre os sistemas. Afinal, sempre vamos depender uns dos
outros em algum momento.
Um sistema lento no ar, muitas vezes, é pior do que um sistema fora do ar, pois
isso gera algo que chamamos de efeito dominó. Imaginemos a seguinte situação:
chamamos o sistema “A”, que chama o sistema “B”, que chama o sistema “C”.
Por algum motivo, o sistema “C” está lento, por isso o sistema “B” ficará travado
esperando sua resposta. Sabemos que nosso sistema “A” está dependendo do
sistema “B”. E quanto mais requisições chegam, terá um momento que o sistema
“B” não irá aguentar mais recebê-las por causa do “C”. E, nessa situação, o “A”
também poderá travar. No final, isso pode fazer com que todos os sistemas caiam.
Assim, por vezes, seria melhor que o sistema “C” estivesse fora do ar. É melhor
dizer que não está aguentando mais lidar com tantas requisições do que não
retornar as respostas.
Resumidamente, quando falamos em se proteger e ser protegido, é melhor

utilizarmos táticas de admitir não estar aguentando mais requisições e retorná-
las para todos do que ficar impedindo a fila de progredir. Pois, dessa maneira,
todos saberão que estamos com problemas. Essa, por incrível que pareça, é uma
forma de proteção. E também parametrizar o que faremos em nosso sistema caso
percebamos que a solução que estamos tentando nos comunicar está cada vez
mais lenta.
Podemos perceber que essa dificuldade não está relacionada a programação. Não
é sobre ser um bom programador de java ou de .net. O que estamos querendo
repassar são conceitos que nos farão trabalhar com excelência, por exemplo, em
um mundo distribuído.
Health Check
O trabalho com health check nos possibilita saber como está a saúde do
nosso software. Assim, conseguimos responder aos outros sistemas se temos
ou não condições de receber mais requisições. Essa é uma forma de fazer uma
checagem de saúde em nossa solução. Por ser um termo muito conhecido, é bem
provável que muitos de nós já tenhamos ouvido falar no trabalho com uso das
regras de health check. Apesar disso, é importante sempre vermos/revermos as
possibilidades de verificação dos sinais vitais da nossa aplicação. Sem isso não é
possível saber como está a saúde de um sistema.
Então, se estamos falando sobre proteger e ser protegido, é essencial que

possamos verificar se podemos mandar ou receber mais requisições. Precisamos
de algum mecanismo que, de tempos em tempos, faça essa checagem. Por
exemplo: se nosso software demorar 5 segundos para responder uma requisição
que deveria ser respondida em 500 milissegundos, pode significar que algo está
errado. Outro exemplo de um possível bug no sistema seria não conseguirmos
acessar o banco de dados.
Baseado nas informações do health check, saberemos se o sistema está saudável

o suficiente para receber mais requisições. Caso a resposta seja negativa, teremos
que pensar em alguma estratégia de adaptação para nosso software. Um exemplo
seria retornar um “erro 500” até que ele se restabeleça. Todos que baterem em
nossa solução não perderão tempo, pois o erro estará sinalizado na tela, com isso,
ele pode procurar alguma forma criativa para lidar com nossa indisponibilidade
ao invés de continuar mandando mais requisições para quem não tem condições
de responder.
Um sistema que não está saudável possui uma chance de se recuperar caso o
tráfego pare de ser direcionado a ele temporariamente. Vamos imaginar que
temos um sistema que tem muito tráfego, quando ele tenta fazer uma consulta
ao banco de dados, tem um retorno muito lento. Depois disso, acaba travando.
Isso fez com que ele começasse a sobrepor várias requisições. Ele não consegue
mais lidar com todas essas requisições, por isso continua muito lento, até que
em certo momento passa a dar timeout. Durante esse processo as requisições
continuavam chegando, o que prejudicava ainda mais o funcionamento desse
software. Por outro lado, vamos imaginar que os outros sistemas pararam de
mandar requisições assim que ele começou a ficar lento. Provavelmente, ele
iria pegar todas as requisições travadas, em algumas daria timeout e as que
restassem poderia começar a processá-las até ficar 100% novamente. Quando
isso acontecesse, passaria a receber novas requisições.
É essencial que tenhamos um health check de qualidade. Quando temos os dados

dos sinais vitais corretos, conseguimos verificar se o sistema não está saudável.
E, dependendo do sistema, existe a possibilidade dele se recuperar. Chamamos
isso de self-healing, ou seja, autocura.
Muitos trabalham por padrão com health check da seguinte forma: o dev coloca
um “health” e a cada 10 segundos manda um ping acessar aquela URL. Caso esta
retorne, o dev chega à conclusão que o software está retornando com qualidade.
O problema é que existe uma diferença muito grande entre acessarmos uma
URL que retorna somente o HTML, de acessarmos uma que retorna uma URL
que pega a média do tempo das últimas requisições e faz uma consulta no banco
de dados. Pois toda vez que criamos uma URL para verificar a saúde do nosso
sistema, essa saúde não pode ser medida somente pelo arquivo de HTML, já que
se tiver um Nginex na frente, sempre terá um retorno incorreto, porque é muito
difícil que o Nginex caia. Assim, é importante criarmos esse arquivo de forma
estratégica, incluindo os dados que serão acessados.
Rate limiting
Rate limiting é uma estratégia que protege o sistema de acordo com o que ele
foi projetado para suportar. Também é um ponto que se relaciona diretamente
com a resiliência da aplicação. Normalmente quando subimos um sistema no
ar temos uma ideia de quanto de requisições ele pode aguentar. Caso não
tenhamos, é recomendável fazermos um teste de stress. Além disso, podemos
ver na empresa quanto de orçamento em relação a quantidade de máquinas
está liberado para nossa solução. Mas é importante sabermos esse limite, pois
senão teremos complicações em nosso trabalho. Então, é essencial buscarmos
essas informações antecipadamente, antes mesmo do problema acontecer. Ao
sabermos esse limite, podemos, então, trabalhar com rate limiting. Assim, se o
sistema consegue responder 100 requisições por segundo, essa será a regra, esse
será o número que vamos trabalhar na estratégia.
No rate limiting podemos dizer que determinado sistema vai aguentar 100
requisições por segundo, passando disso retornará um “erro 500”, por exemplo.
Então o sistema poderá trafegar com qualidade, ou um nível de qualidade
mínima, até o ponto determinado, pois acima desse ponto começará a atrapalhar
os outros sistemas.
Para compreendermos como tudo isso funciona, vamos imaginar uma situação
hipotética: temos um cliente que utiliza nossa API e esse cliente faz em média
50 requisições por segundo, ou seja, ele tem metade do que normalmente

conseguimos prover. Nesse contexto, temos diversos outros sistemas que não
possuem tanta prioridade. Por serem sistemas periféricos, não trazem um
nível de criticidade ao negócio caso estejam fora do ar. Para completar nosso
raciocínio, vamos pensar agora em dois personagens: Pedrinho e Zezinho e os
dois são de outro squad. Digamos que Pedrinho tem um sistema que não é tão
crítico para a organização quanto o de Zezinho. Ao sair, Pedrinho esqueceu um
loop ligado, então esse sistema, que não é tão importante, vai começar a fazer
pelo menos 100 requisições em nossa solução. Desse modo, aquele sistema do
Zezinho, que é bem mais importante, não vai conseguir acessar porque tem uma
rate limiting permitindo somente 100 requisições por segundo. Assim, estaremos
dando prioridade a um site que nem é tão crítico para o negócio, deixando de fora
um sistema que tem um nível de criticidade muito mais alto para a corporação.
Então, para evitarmos isso, precisamos gerar preferências por clientes quando
trabalhamos com rate limiting. Podemos programar da seguinte forma: Zezinho
tem pelo menos 60 requisições por segundo e o Pedrinho fica com as outras
40. Dessa forma, por mais que outras aplicações tentem “bombardear” nosso
sistema, não conseguirão passar do limite e nos afetar. Fora isso, o sistema que
realmente precisa utilizar o nosso, vai acessar de forma prioritária.
Então, quando se trata de rate limiting, é importante também determinarmos

um limite programado por tipo de cliente. Ou seja, ajustar as preferências e as
prioridades que queremos trabalhar. Assim, evitamos que sistemas críticos, que
dependem de nós, não fiquem sem acesso.
Circuit breaker
Através do circuit breaker as requisições feitas para um sistema podem ser

negadas, por exemplo por meio da devolução instantânea de um “erro 500” para
o cliente. Dessa forma conseguimos proteger a nossa aplicação.
Mas antes de explicarmos como isso funciona, é importante apresentarmos

três formatos de circuitos possíveis: o circuito fechado, o circuito aberto e o
circuito meio aberto. O primeiro acontece quando as requisições estão chegando
normalmente, isto é, mandamos as requisições e elas chegam de modo “normal”
porque esse circuito está fechado. No segundo temos o contrário disso; as
requisições não chegam à aplicação pois passamos instantaneamente um “erro”
para o cliente. Então, com o circuito aberto, os que tentam acessar nossa solução
deverão pensar em estratégias para que suas aplicações sejam resilientes. Já o
terceiro, podemos considerar como um meio termo. Neste caso, é permitida
uma quantidade limitada de requisições para que seja feita uma verificação
da possibilidade de recebimento destas pelo sistema. É um teste que permite a
entrada de certa quantidade de requisições por um determinado tempo. Assim,
é possível saber se o sistema tem condições ou não de voltar ao ar integralmente.
Para compreendermos melhor como isso tudo funciona, vamos imaginar que
temos um circuito elétrico com um disjuntor em nossa casa e este disjuntor
vai servir para abrir o circuito caso venha uma sobrecarga. Assim, ao invés da
corrente elétrica continuar passando - o que poderá queimar nossos eletrodo-
mésticos -, ele abrirá o circuito, fazendo com que essa corrente pare ali.
O circuit breaker funciona de forma semelhante a um disjuntor nos sistemas.

Quando o circuito está fechado, significa que uma solução se comunica nor-
malmente com a outra. Mas digamos que exista uma aplicação chamada de
“A” que se comunica com outra chamada de “B”. A primeira começou a ter
dificuldade para responder a segunda. Assim, a solução “A” passou a amontoar
as requisições, gerando aquele efeito dominó que comentamos anteriormente.
Nesta situação, o circuit breaker vai abrir o circuito e a solução “B” receberá um
“erro 500” até que a solução “A” possa começar a se recuperar. Somente após a
recuperação o circuito será fechado novamente.
Com uso de códigos é possível implementarmos o circuit breaker em nosso

próprio sistema, inclusive existem bibliotecas que fazem isso. Conseguimos,
dessa maneira, segurar nossa aplicação e a dos outros. Porém, é importante
sabermos que existem recursos mais modernos hoje em dia, um exemplo é
quando estamos trabalhando com service mesh. Nesse caso, o circuit breaker
é aplicado diretamente na rede, assim o desenvolvedor não precisa se preocupar
com isso.
API Gateway
Uma API Gateway funciona, basicamente, como uma porta de entrada em

nosso sistema. Ela centraliza o recebimento de todas as requisições que estão
acontecendo em nossa aplicação.Ou seja, ela pode aplicar, logo na entrada, re-
gras, políticas, plugins etc. Assim, consegue perceber as necessidades individuais
de cada serviço. Baseado nisso, pode rejeitar, ou tomar diversas decisões que
favoreçam as aplicações.
Quando falamos em resiliência, esta solução nos ajuda a evitar uma série de
situações que poderiam prejudicar nossa aplicação. Por exemplo, imagine que
temos um sistema em que o usuário precisa ser autenticado para acessá-la.
Digamos que alguém crie um robô para “bater” nessa aplicação repetidamente,
nosso servidor tentará fazer a autenticação das requisições feitas por ele. Ou seja,
ao detectar usuário e senhas diferentes, nosso software vai retornar um “não”.
Isso, feito várias vezes, fará com que esse serviço processe inúmeros pedidos,
o que provavelmente prejudicará seu funcionamento. Em uma situação dessas,
a API Gateway tem condições de validar da seguinte forma: se alguém está
batendo em nossa máquina precisa fornecer um token JWT para ser autenticado,
por exemplo. Assim, se ele não conseguir ser validado logo na API, não passará
nem desta portaria. É como se morássemos em um condomínio fechado. Então,
se alguém quiser bater a campainha da nossa porta, ele terá que passar primeiro
pela portaria. De modo semelhante, o usuário terá que passar pela API Gateway
caso queira acessar nossa aplicação.
Tem sido cada vez mais comum ver empresas utilizando API Gateway. Pois as
grandes APIs do mercado tem recursos e plugins que auxiliam muito no dia a
dia das aplicações. Um bom exemplo de uma API famosa é a Kong. Ela pode
ser usada tanto standalone, isto é, na frente de diversas aplicações, como em um

under control em um Kubernetes. É interessante dizermos também que a Kong
usa, por trás dos panos, o próprio Nginex.
Com os diversos plugins que a API Gateway nos oferece, podemos trabalhar com
rate limiting e health check. Ou seja, conseguimos dizer para a URL receber até
100 requisições por segundo, sendo que seriam reservadas 50 requisições para
os usuários autenticados e os restantes dos usuários ficariam com as outras 50.
Assim, conseguimos trabalhar com limites e prioridades. Além disso, é possível
fazermos a verificação da saúde de forma ativa para que possamos perceber
claramente se aquela aplicação está saudável. Isto é, a própria API Gateway faz
o apontamento da saúde da aplicação e retorna um “erro” para quem estiver
chegando, caso seja necessário. Por outro lado, se a solução estiver saudável,
coloca o usuário dentro do sistema.
Então, podemos perceber que recursos como esses podem facilitar nosso dia
a dia. A API Gateway tem tantas funcionalidades que é necessário tomarmos
cuidado para que ela não aplique, involuntariamente, regras de negócio. Por
exemplo, podemos colocar um plugin para que todas as vezes que recebermos
um XML, este seja transformado em um JSON, caso nosso programa não
consiga trabalhar com esse XML. Ou, eventualmente, se tivermos uma Lambda
Function e queremos que, quando o usuário acesse a “axpto.com.br/produtos”,
seja executada uma Lambda na AWS. Então, a API Gateway consegue fazer
esse tipo de tarefa.
Assim, percebemos que essa solução nos oferece diversas funcionalidades, de

fato, que contribuem para o bom desenvolvimento dos sistemas. Pois ela con-
segue trabalhar desde autenticação, autorização, rate limiting, transformações,
adição/remoção dos headers, até trabalhar com logs. Mas o que queremos
destacar, neste tópico, é que a API Gateway pode nos ajudar a colocar diversas
estratégias que auxiliam no processo de resiliência dos nossos softwares.
Service mesh
De modo geral, a service mesh, ou malha de serviços, tem um conjunto de

recursos que nos ajudam a controlar o tráfego de rede. Por isso, tem sido muito
usada pelas organizações. Atualmente, temos diversas mesh no mercado, mas
podemos citar a Istio como um exemplo. Neste tópico, nos dedicaremos a fazer
uma relação entre esta solução e a resiliência dos sistemas.
O trabalho com service mesh é feito, basicamente, colocando proxies do lado

de cada sistema. Uma vez feito isso, sempre que um serviço se comunicar com
outro, isso não será feito diretamente. Por exemplo, em uma situação hipotética,
estamos usando uma mesh e temos uma conversa entre o sistema “A” e o “B”.
Logicamente, eles pensam que estão tendo essa comunicação diretamente, mas
na verdade a solução “A” enviou uma mensagem para um proxy, que chamamos
de sidecar. E é esse sidecar que enviará a requisição para o sistema “B”. Caso o
serviço “B” também tenha um proxy, este receberá a requisição e depois mandará
para o sistema “B”. Então, isso significa que quando trabalhamos com service
mesh toda comunicação de rede é efetuada via proxy. Assim, tudo que estamos
passando na rede consegue ser controlado e medido. Conseguimos pegar os
dados, saber quem manda/recebe as informações, como e o quanto de tempo
essa informação é processada, etc. É extremamente interessante saber isso tudo,
pois assim conseguimos entender o comportamento da nossa rede e controlá-la.
Ao fazermos isso, podemos dominar tudo o que está acontecendo.
Ainda sobre comunicação entre os sistemas, vamos imaginar algumas ações que
precisaremos fazer em nossa aplicação em algum momento. Primeiro vamos nos
lembrar do rate limiting. Como poderíamos fazer sua implantação? A resposta
é que teríamos que instalar uma biblioteca ou criar uma implementação em
nossa aplicação. E, nessa aplicação, guardaremos, no banco de dados, quantas
requisições estamos recebendo por segundo. Além disso, teríamos que separar
essas requisições por cliente, para ver quando seria necessário negá-las. Vamos
nos lembrar também de quando fazemos uma requisição e o sistema não nos
retorna. Nesta situação, precisamos fazer um processo chamado de retry, ou
seja, tentar novamente para verificar se aquele sistema estava fora do ar. Uma
alternativa de como fazer isso seria realizarmos algumas tentativas em nossa
biblioteca, uma vez, duas vezes, três vezes… ou quantas vezes forem necessárias.
Outra situação para pensarmos é na implementação do circuit breaker em nosso
projeto. Primeiro, seria necessário medir mais ou menos a saúde da nossa aplica-
ção. Depois, quantas requests ela está recebendo por segundo. A partir dessas
informações podemos começar a negar, ou seja, abrir o circuito. Com esses
apontamentos, podemos perceber que existem diversos comportamentos que
são relacionados à comunicação da aplicação. E nós, normalmente, acabamos

fazendo isso no código. Sobre tudo isso, podemos dizer que o mais complexo é
projetar em qual propriedade nós, desenvolvedores, podemos codificar.
A service mesh provê uma forma de conseguirmos olhar tudo o que está
acontecendo de comunicação entre seus sistemas. Além disso, possibilita aplicar
alguns comportamentos como rate limiting e circuit breaker direto na rede,
porque teremos acesso aos proxies. Então, se quisermos fazer um circuit breaker
antes da requisição bater em nossa solução, com uma mesh ela baterá em
nosso proxy. O nosso proxy saberá que estamos ruins, assim, abrirá o circuito,
impedindo que a requisição bata em nossa aplicação.
Sabemos que atualmente todas as comunicações que acontecem entre os nossos

sistemas devem ser criptografadas, pois sempre é possível que tenhamos alguém
em nossa rede tentando interceptar essas mensagens, inclusive chamamos isso
de ataque man-in-the- middle. Através de uma service mesh podemos trabalhar
com uma Mutual TLS (mTLS). Assim, quando um sistema quer se comunicar
com o outro nós criamos uma relação criptografada entre eles. Por exemplo,
temos o serviço 1 e o serviço 2 tentando se comunicar. E o 2, ao ser chamado pelo
1, quer saber se realmente esse sistema é quem diz ser. Ao trabalhar com mTLS,
por meio dos proxies, o serviço 1 consegue mostrar uma chave de criptografia
para que o serviço 2 tenha certeza de que pode trafegar as informações. Fazer
tudo isso manualmente em uma rede é algo insano, pois teríamos, além de
outras coisas, que controlar a geração de certificados. Em sistemas realmente
grandes seria uma tarefa muito complicada, porque trabalhamos com milhares
de microsserviços. Com uma service mesh, conseguimos isso imediatamente e
com poucas configurações. Então, é essencial considerarmos a importância de
conhecer ao menos o básico sobre essa solução. É importante dizermos que nosso
objetivo, neste curso, não é infraestrutura, por isso nossa finalidade não é fazer
com que os devs compreendam tudo sobre rede. Por outro lado, é essencial que
todos nós saibamos que existem tecnologias e soluções que podem suprir, muitas
vezes, papéis que em tese nós pensávamos ser da pessoa desenvolvedora, mas
que com os recursos que temos hoje não precisa mais ser.
A service mesh nos possibilita trabalhar de forma automática com circuit

breaker, com políticas de rate limiting, de retry, de timeout, de fault injection
etc. Assim, saberemos qual será o comportamento se metade da rede cair, se é
possível fazer testes entre outros. Isso só é possível pelo controle que uma mesh
nos proporciona.
Trabalhar de forma assíncrona
O trabalho de forma assíncrona é extremamente antigo, ou seja, as pessoas usam

essa forma de trabalhar há bastante tempo. Por exemplo, vamos nos lembrar
de quando precisamos fazer um pagamento em um banco ou supermercado.
Imagine que, na maioria das vezes, não tem uma quantidade suficiente de caixas
para atender os clientes. Logo, é necessário organizar essas pessoas em filas.
Pois, já que eles não conseguem absorver a quantidade de requisições que estão
chegando, é necessário que esses clientes fiquem em espera para fazer o seu
pagamento. Então, podemos perceber que entrar em uma fila para aguardar
uma solução é algo que já fazemos em diversas situações de nossas vidas,
em diversas ocasiões não temos nossos problemas resolvidos instantaneamente.
Porém, quando estamos trabalhando em sistemas, nós acabamos não pensando
dessa forma.
Caso uma aplicação esteja recebendo 100 requisições por minuto, quando
aguentaria somente 50 requisições nesse tempo, essas que estão sendo enviadas
a mais ficarão travadas e, eventualmente, perderemos uma ou outra requisição.
Isso não faz sentido, porque aquela pessoa que nos enviou a requisição pode
não estar esperando a resposta exatamente naquela hora. Mesmo que ela
tenha enviado logo a requisição, provavelmente poderia esperar. Porém, nós só
estamos dando uma opção, ou seja, se alguém quer nos mandar uma requisição
vamos responder imediatamente e, como não conseguimos fazer isso, preferimos
perder a requisição.
Quando falamos em trabalhar de forma assíncrona, estamos falando em fazer

exatamente como os bancos e supermercados: quem quiser nos mandar mensa-
gem, poderá ficar aguardando na fila. Quando chegar a sua vez iremos resolver
os seus problemas. Trabalhar desse modo evita perder dados, porque com
menos recursos computacionais conseguiremos dar vazão a mais requisições do
que poderíamos dar se estivermos sobrecarregados. Isso acontece porque não
precisamos entregar as respostas dessas solicitações imediatamente. E, como
conseguimos dar conta de mais requisições, consequentemente não perdemos

dados.
Além disso, não há perda de dados no envio de uma transação se o servidor

estiver fora do ar. Vamos imaginar que temos um sistema e este estava “reboo-
tando”. Isso acontecia quando alguém nos mandava solicitações de pagamento.
Isto é, por algum momento teve uma falha, estava usando máquina virtual e
subindo. Assim, a pessoa que enviou a requisição percebeu que não havia como
fazer o pagamento, logo, deveria tentar em outro momento. Nesta situação seria
válido trabalharmos de forma assíncrona. Se esperamos ter a resposta naquela
hora, mas não dá, aquele sistema que está “rebootando” perderá os dados. Porém,
se trabalharmos de modo assíncrono, permitiremos opções diferentes. Nossa
aplicação não precisará, necessariamente, processar tudo o que enviam para ela
de modo instantâneo. Então na hora que um usuário enviar uma mensagem,
ao invés dessa mensagem ir direto para nosso sistema, ela é enviada para um
intermediário que irá armazenar somente a informação. Quando o sistema que
está sendo requisitado estiver pronto, ele vai ler desse sistema do meio, para
depois processar a informação. Ou seja, o servidor pode processar a transação em
seu tempo quando estiver on-line, assim os dados não são perdidos pois estarão
no intermediário, que normalmente é chamado de message broker.
Message broker é um sistema específico para receber requisições. Ele funciona

da seguinte forma: recebe e guarda a solicitação, sem lê-la ou processá-la. Depois,
quando a aplicação estiver disponível, ele entrega essa requisição para que seja
processada. Trabalhando assim, nossa solução consegue receber mais requisições

do que poderia, pois essas solicitações são processadas aos poucos. Porém, o mais
importante de tudo isso é que mantemos a resiliência porque não perdemos os
dados.
É importante sabermos que, muitas vezes, ao começar o trabalho de forma

assíncrona as pessoas desenvolvedoras procuram diversas soluções e ferramen-
tas como webMQ, Kafka, SQS. Fazendo isso, elas têm a ideia de que é só
mandar e receber que tudo funciona bem. Mas a nossa sugestão é que as
pessoas entendam com profundidade seu message broker. É essencial que se
compreenda bem o sistema ao utilizá-lo, pois algumas vezes a forma como
estamos usando pode ser inadequada e, ainda assim, perderemos dados. Então,
é importante compreendermos bem o seu funcionamento e as garantias de
recebimento/entrega para utilizarmos essas soluções da melhor forma possível.
Garantias de entrega com Retry
Quando queremos desenvolver um software resiliente, o primeiro ponto que

devemos observar é se temos a garantia de que nossas chamadas serão entregues.
Ao realizarmos uma requisição, é essencial termos a garantia de que a mensagem
que estamos enviando está chegando ao destino. Mas sabemos que nem sempre
isso acontece, pois o outro sistema pode estar lento, fora do ar, etc. Uma
alternativa para minimizar esses problemas é trabalhar utilizando políticas de
retry.
Essas políticas são basicamente a tentativa de reenvio da mensagem. Ou seja,

mandamos uma mensagem e se o outro sistema não respondeu por determinado
tempo, mandamos outra. Caso ele não responda novamente, continuamos
tentando até o sistema responder.
Então, se observamos o gráfico abaixo, retirado de um artigo da Amazon

(https://aws.amazon.com/pt/blogs/architecture/exponential-backoff-and-
jitter/), veremos que à direita temos o work (calls) que são as quantidades
de chamadas realizadas para um serviço e em sua parte de inferior temos a
quantidade de clientes que estão competindo para conseguir realizar aquela
chamada.
Linear - Sem backoff
Para compreendermos melhor o funcionamento dessa estratégia, vamos ima-

ginar que temos 10 sistemas tentando fazer uma chamada em outro serviço.
Digamos que esses 10 clientes resolveram fazer uma chamada ao mesmo tempo.
Isso significa que todos vão bater no serviço ao mesmo tempo. Provavelmente,
este outro serviço terá dificuldade em lidar com isso e acabar travando. Os
sistemas que estão tentando se comunicar com ele poderão enviar a mensagem
novamente depois de 2 segundos, e depois de aguardar mais 2 segundos para
enviar outra mensagem. Lembrando que os 10 clientes farão isso de maneira
simultânea, logo, se o sistema não conseguiu antes, dificilmente conseguirá
depois desses intervalos. Isso quer dizer que não adiantaria fazer o retry da
chamada de forma linear - a cada 2 segundos, 3 segundos -, pois todos os sistemas
estão fazendo retry ao mesmo tempo, o que continuará sobrecarregando o
serviço.
Por conta disso, existem algumas técnicas que aumentam a probabilidade de

conseguirmos fazer um retry com sucesso, por exemplo: o exponential backoff.
Vamos observar que no próximo gráfico a linha rosa representa onde não
tínhamos backoff, ou seja, era totalmente linear, e por isso o tempo para
conseguirmos ser respondidos na chamada era extremamente longo. Com o
exponential backoff, representado pela linha verde, a situação é um pouco
diferente. Nesta técnica daremos um tempinho a mais para que o serviço consiga
responder. Na prática, se mandamos uma chamada e esta não é respondida,
esperamos 1 segundo e mandamos um retry. Depois, caso ele continue não

nos enviando a resposta, ao invés de esperarmos 1 segundo novamente, espe-
ramos 2 segundos, depois 4, 8, 16… ou seja, repetimos a tentativa de forma
exponencial para que durante esse tempo possamos dar mais espaço para que
o sistema consiga se recuperar. Porém, com essa estratégia ainda teríamos
bastante dificuldade em relação ao tempo para conseguirmos uma resposta
porque apesar dos números terem melhorado um pouco, provavelmente esses 10
clientes também estarão trabalhando de modo exponencial. Os 10 vão esperar 2
segundos, depois 8 segundos, 16 segundos… Isso irá melhorar um pouco pois
algumas requisições que estavam travadas serão liberadas, mas ainda assim,
como podemos observar no gráfico, não teremos uma melhora significativa. Isso
acontece porque um exponential backoff utiliza sempre os mesmos algoritmos
para fazer seus processos de retry.
Exponential backoff
Se todos os clientes começarem a fazer chamadas a partir de agora, de modo

simultâneo, dificilmente o sistema conseguirá responder a essas solicitações.
Uma alternativa para essas dificuldades é utilizar o exponential backoff com
jitter. Nessa estratégia colocamos uma espécie de mini algoritmo em nossa
requisição para gerar um pequeno ruído no tempo de chamada. Caso tenhamos
problema na hora em que formos fazer uma chamada para 1 segundo, e formos
fazer a solicitação de 2 segundos, colocaremos 2.1, na outra solicitação 2.05,
depois 2.25, em seguida 2.3 até conseguirmos. Podemos perceber que pelo fato
de termos um pequeno ruído nesse algoritmo - os números não são mais
exatamente iguais -, conseguiremos fazer com que tentativas simultâneas sejam

evitadas. Assim, as tentativas acontecem em momentos diferentes, aumentando
as chances da requisição funcionar. Podemos observar no gráfico abaixo como
foi possível diminuir a quantidade de chamadas conforme o número de clientes
aumentava.
Exponential backoff- Jitter
Isso nos mostra que todas as vezes que trabalhamos com políticas de retry é
extremamente válido inserirmos o jitter, ou seja, vamos adicionar algoritmos de
ruídos para que nossa requisição não seja exatamente igual a dos outros clientes.
Assim, o sistema não terá que lidar com requisições simultaneamente, tendo
mais chances de trabalhar.
Então, caso não sejamos respondidos na primeira vez que solicitarmos, com essa
estratégia temos mais chances de alcançarmos o resultado esperado em nossa
segunda tentativa. O que queremos destacar, neste tópico, é a necessidade de
sermos espertos em nossas novas tentativas. Porém elas precisam ter lógica, os
números colocados não são meros palpites.
Garantias de entrega com Kafka
Uma das formas de termos garantia de entrega é utilizando um broker. Neste

tópico escolhemos um em específico para usarmos como exemplo, o Kafka.
Mas é importante sabermos que a maioria dos brokers trabalha de forma
semelhante. Por isso não queremos destacar, necessariamente, o comportamento
dessa solução, mas sim o quão longe vai a possibilidade de garantirmos a entrega
de uma informação por meio de um broker.
Em relação à resiliência, é importante pensarmos em como garantir que nossas

informações não serão perdidas. Além disso, temos que buscar a garantia de
que essas informações serão, de fato, processadas pelo sistema que chamamos.
Para isso, podemos trabalhar de forma assíncrona, pois essa forma de trabalho
pode nos ajudar a lidar com mais informações do que poderíamos. Então, nesse
modo de trabalho temos a alternativa de utilizar um message broker, ou seja,
um sistema que armazena nossas requisições e depois possibilita que elas sejam
lidas em outros sistemas. Mas precisamos ter a certeza de que a informação que
estamos enviando para o kafka, por exemplo, está chegando até ele e ter certeza
de que a requisição não será perdida no meio do caminho. Normalmente, gosto
de “brincar” que cada transação que envio tem o valor de 1 milhão de dólares,
então, não posso perdê-la de forma alguma. Porém, quando se trata de resiliência,
tudo tem um lado bom e um lado não tão bom. Veremos isso nos próximos
parágrafos.
Partindo do princípio de que não sabemos muito sobre o Apache Kafka, vamos
imaginar que mandaremos uma mensagem para que essa solução guarde até que
o outro sistema possa processá-la. Quando trabalhamos com alta disponibilidade
teremos um cluster, isto é, um conjunto de brokers. Nesse caso, falando especifi-
camente do Kafka, teremos o broker “A”, “B” e o “C”. A mensagem que enviamos
cairá em um broker “A”, que é chamado de líder. Sabendo disso, temos alguns
pontos para pensarmos em relação à garantia de entrega. Primeiro, podemos
optar por não ter uma confirmação de entrega, logo não temos certeza de que
nossa mensagem foi recebida. Podemos escolher essa opção dependendo do nível
de importância da mensagem.
Por exemplo: se mandarmos uma carta pelos correios e simplesmente aguarda-

mos sua entrega, provavelmente nossa encomenda é algo que não tem tanta
importância, por isso escolhemos não ter sua garantia de entrega. Mas se
precisarmos ter a certeza de que o correio entregou a encomenda, podemos pagar
um valor a mais pela garantia de recebimento. Neste segundo caso, ele nos envia
a confirmação de que o enviado foi, realmente, recebido. Semelhantemente,
temos essa opção quando enviamos uma mensagem ao nosso broker: ter ou não
a garantia de entrega.
Vamos imaginar, ainda, que estamos trabalhando com o Uber. A cada momento
o aplicativo nos mostra a posição do motorista e do passageiro. Mas o que
aconteceria se perdêssemos algumas dessas posições? Seria um problema gra-
víssimo para o negócio? Acreditamos que não. O aplicativo pode nos mostrar
o máximo de posições possíveis, ou seja, mesmo que algumas posições sejam
perdidas, o mais importante é que sejam mandadas o maior número possível.
Como não pedimos uma confirmação, esse uber fica mais rápido. Isso acontece
porque só está recebendo, sem necessitar pausar para confirmar que recebeu.
Logo, podemos perceber que todas as vezes que não pedimos a confirmação de
entrega ganhamos velocidade. Porém, existe a possibilidade de perdermos uma
mensagem ou outra. Podemos chamar isso de fire-and-forget, isto é, disparamos,
esquecemos e torcemos para que a mensagem seja entregue.
Existem alguns casos em que não podemos trabalhar desse modo, pois precisa-
mos, necessariamente, ter a certeza de que o broker recebeu a mensagem. Isso
pode acontecer porque a mensagem é muito importante, por exemplo 1 milhão
de dólares. Neste caso, devido à sua importância, precisamos ter a confirmação
de que o broker líder realmente recebeu a requisição. Mandamos a solicitação e
o líder nos retorna um Ack1, ou seja, a confirmação que precisamos ter.
Porém, vamos supor que temos 3 brokers e essas informações ficam replicadas,
assim, caso um caia o outro poderá assumir. Digamos que nós enviamos uma
solicitação para o broker “A” e ele nos deu um retorno de recebimento, neste caso
ficamos tranquilos. Mas em seguida, por algum motivo, esse broker caiu. Sem
saber da queda, pensaremos que a mensagem está segura, porém, por alguns
momentos nossa mensagem não teve alta disponibilidade. Isso pode fazer com
que percamos alguma mensagem.
Uma alternativa para evitarmos o problema anterior é trabalharmos com Ack-1

ALL. Neste modo de trabalho, mandamos a mensagem para o broker “A” e antes
de nos responder ele manda essa mensagem para o broker “B”. Em seguida, o
“B” envia para o broker “C”. Somente depois disso temos um retorno de que
a mensagem já foi sincronizada entre os 3 brokers. Dessa maneira, teremos a
certeza de que a mensagem, de fato, está segura, pois caso um dos brokers caia,
os outros ainda mantêm nossa requisição disponível.
Resumidamente, se queremos alta velocidade para mandar as mensagens, fare-

mos Ack 0, mas sabemos que podemos perder alguma dessas requisições. Se
queremos algo moderado, podemos fazer um Ack 1, ou seja, ter a confirmação
do líder. Mas se quisermos maior garantia possível, trabalharemos com Ack-1
ALL.
Essas observações não são apenas para o kafka pois existem outros sistemas que
trabalham de forma similar. Essa solução foi utilizada apenas para termos um
exemplo prático. Diante de tudo isso, o que queremos destacar é que precisamos
ter uma noção do nível que as coisas chegam em relação a garantias quando
trabalhamos de forma assíncrona. Isso porque não se trata apenas de mandar
uma mensagem. É importante entendermos, com um nível de profundidade, o

broker que estamos trabalhando. Assim podemos garantir que a nossa mensa-
gem está chegando ao destino esperado. Então, se pensarmos novamente no
exemplo de 1 milhão de dólares, qual seria a melhor opção: usar Ack 0 ou Ack-1?
Para garantirmos a resiliência precisamos compreender o custo benefício dessa
resiliência. Tanto em relação à performance, quanto em relação à segurança dos
dados que queremos ter.
Situações complexas e decisões de alto nível
A resiliência deve ser pensada no dia zero e de forma intencional, pois é

algo extremamente importante para a sustentabilidade do software. Por outro
lado, existem situações complexas que fazem com que nossos planos para
tentar que as soluções sejam mais adaptáveis falhem. Então, neste tópico, nos
dedicaremos a fazer alguns questionamentos que podem auxiliar na reflexão de
como conseguir isso de fato. Com isso, não buscamos oferecer soluções prontas,
mas sim pensamentos capazes de nos fazer analisar sobre aspectos importantes
para a tomada de decisões que garantam a resiliência que nosso sistema precisa
ter.
A primeira pergunta que devemos fazer é: como ter a resiliência da resiliência?

Vamos trazer alguns exemplos práticos que poderão nos ajudar a pensar com
mais clareza sobre isso.
Digamos que nós temos um broker que apoia nossa aplicação. O que aconteceria
se este caísse? Se o Kafka caísse? Ou o SQS? Ou o RabbitMQ? Perderíamos

mensagens? É possível dizermos como nosso sistema vai se comportar? Devemos
pensar nisso, pois existem sistemas que não sobem caso não consigam se
comunicar com o RabbitMQ, por exemplo. Precisamos pensar em como garantir
a resiliência em situações inusitadas.
Ao observamos bem as aplicações, sempre teremos um single point of failure

(SPOF), ou seja, seria como dizer que estamos apoiando toda nossa resiliência em
determinada solução. Usando o Kafka como exemplo no Kafka, isso significa que
caso o caia, cai tudo em minha solução. Mas como evitar isso? Como preparar
meu sistema para que, caso o Kafka caia, não percamos informações e quando ele
voltar possamos continuar mandando essas informações? Por mais improvável
que as situações pareçam, temos que deixar as aplicações um pouco mais
preparadas em diversas situações. Então, quanto mais situações conseguirmos
pensar, mais resiliência e disponibilidade teremos, o que nos leva a outra questão,
isso será mais caro também.
Pensando, por exemplo, em situações pouco prováveis, qual seria a probabilidade

da AWS cair em uma região inteira? As chances de isso acontecer são poucas. E,
caso acontecesse, poderíamos trabalhar com multizona, ou seja, zonas de dispo-
nibilidade. Configurar nossas máquinas em diferentes zonas de disponibilidades
é gratuito, então não existe um motivo para não trabalharmos com A a Z, pois
se nossa região inteira cair, precisamos migrar rapidamente para outra região,
mesmo que saibamos que a AWS já caiu diversas vezes. Quem dependia apenas
de uma zona de disponibilidade ficou em uma situação complicada, isto é, teve

que trabalhar com duas regiões. Tornando a situação mais improvável ainda,
precisamos ter a disponibilidade de migrar rapidamente para Edge (Google
Distributed Cloud Edge) se a Amazon vier a desaparecer.
Nos dias atuais muitas empresas estão trabalhando com multi-cloud. Muito
provavelmente isso não se dá apenas por uma questão de custos. Está relacionado
à segurança, resiliência e disponibilidade. Então, o que queremos destacar
é que sempre terá um limite para setar nossa resiliência. Ou seja, quanto
mais resiliência, mais esforço e mais caro. Todavia, podemos dizer que não é
responsabilidade do desenvolvedor definir qual é o nível de resiliência, muitas
vezes essa decisão precisa ser estratégica da empresa, pois em níveis elevados,
saberão quais riscos a organização está disposta a ter para o negócio. Diferente de
decisões que envolvam comunicação entre sistemas, perda de dados, tentativas
de retry. Estas são responsabilidades dos devs.
A resiliência é algo extremamente complexo, pois além de envolver um gerenci-

amento de riscos, a cada 99.999 que colocamos em nosso sistema custará muito
mais caro para nossa empresa. Ou seja, teremos que definir e gerenciar riscos
para nosso chefe ou com nosso CEO.
Para pensar em resiliência terá que ser definido os custos, a necessidade de mais
mão de obra, etc. Isso significa que essas decisões são mais alto nível por envolver
dinheiro, especialidades, etc. Assim, será avaliado, como já dissemos, o custo
benefício relacionado à necessidade de ter um sistema resiliente.
Sistemas Monolíticos
Sistemas “tradicionais”
Nada melhor de que exemplos concretos para facilitar entendimento quando

falamos em desenvolvimento de sistemas, logo, para começarmos esse capítulo,
imagine um sistema de gerenciamento de produtos onde tais produtos podem
ser categorizados e disponibilizados para venda. Também tal sistema permite
que o usuário(a) possua uma área de busca, bem como o recurso de checkout
para realizar a compra.
Com isso em mente, já é possível termos ideia de outras áreas que poderiam
existir dentro desse sistema, como um catálogo para exibição dos produtos,
evoluindo assim para uma loja virtual.
Podemos utilizar plataformas para desenvolver tal loja como um Magento por
exemplo.
Essa é uma abordagem super comum principalmente devido a evolução de

ferramentas, CMSs e frameworks. Todos os recursos fazem parte de uma mesma
aplicação.
Sistemas Monolíticos 121
Esse é o clássico exemplo de um sistema monolítico, onde todas as opera-

ções acontecem em sua própria estrutura utilizando normalmente uma única
linguagem de programação. Nele, são incorporadas todas as entidades, regras
de negócio, disponibilização de APIs e integrações. Obviamente tudo está
fortemente acoplado em um único sistema que normalmente possui mais de
uma responsabilidade.
Restrições
Pela própria natureza dos sistemas monolíticos, normalmente eles utilizam

uma única linguagem de programação. Por exemplo, se nós temos um sistema
monolítico feito em Ruby, é improvável tenhamos alguma coisa escrita em PHP
ou Python.
Em muitos casos essa possível “limitação” de utilizar uma única tecnologia

dentro de um sistema pode fazer com que a organização não tire proveito de
tecnologias, que para determinados casos de uso, sejam mais eficientes trazendo
assim mais valor para o negócio como um todo.
Além disso, temos que concordar que ao colocarmos, cem, duzentas, ou mesmo
mil pessoas para trabalhar na mesma base de código pode ser em determinadas
situações algo caótico.
Monolitos não são ruins
Apesar das restrições citadas acima, trabalhar com sistemas monolíticos não é
nenhum demérito ou atestado de obsolescência.
Sistemas monolíticos na maioria das vezes sem dúvidas é a melhor opção para
grande parte das empresas. Afinal de contas, nem toda empresa possui 6000 devs
como Mercado Livre.
Trabalhar com sistemas monolíticos reduz a complexidade e aumenta a efici-

ência principalmente em situações em que as próprias regras de negócio da
empresa estão em constante mudança. Startups, empresas fazendo validações
de modelos de negócio, bem como corporações que não fazem o uso “pesado”
de tecnologia como principal ponto de sustentação, são grandes candidatas a
trabalharem com sistemas monolíticos.
Via de regra, “todo” sistema deve começar com um monolito.
Martin Fowler em seu artigo MonolithFirst¹ faz duas grandes observações logo
no início:
1. “Quase todas as histórias de sucesso de sistemas utilizando microsserviços

começaram com um monolito que ficou grande e depois foi quebrado em
partes.”
¹https://martinfowler.com/bliki/MonolithFirst.html
2. “Todos os casos que ouvi de sistemas que começaram diretamente utilizando

microsserviços tiveram grandes problemas”
Para que uma companhia inicie o processo de desenvolvimento de seus sistemas

utilizando uma abordagem diferente da monolítica, sem dúvidas os profissionais
ali inseridos devem ter muitas cicatrizes com experiências de sucesso anteriores,
caso contrário, há uma grande probabilidade do projeto fracassar.
Deploy
Sistemas monolíticos possuem uma característica singular quando precisam ir

ao ar. Como tudo encontra-se dentro da mesma estrutura, por mais simples que
seja determinada mudança, o deploy de 100% da aplicação precisa ser realizado.
É evidente que quando todas as áreas de uma empresa estão concentradas em

um único sistema, o risco de interrupção de todas as áreas aumenta a cada deploy
realizado. Em contrapartida, complexidades de comunicação entre diversos
sistemas, a necessidade de criação de uma grande quantidade de pipelines de
entrega, bem como todos os aspectos comuns em entregar e gerir projetos em
produção são reduzidos drasticamente.
Necessidade de escala
Quando trabalhamos com grandes sistemas, invariavelmente teremos a necessi-

dade de escala.
Segundo a definição da Gartner²:
“Escalabilidade é a medida da capacidade de um sistema de aumentar ou

diminuir o desempenho e o custo em resposta às mudanças nas demandas de
seus aplicativos e processamento.”
Nesse ponto, é evidente de que quando temos a necessidade de escalar um sis-

tema monolítico, não há a possibilidade de escalarmos apenas as funcionalidades
que naquele momento estão exigindo mais recursos computacionais, ou seja,
todo sistema precisa escalar.
Por exemplo, se um ecommerce receber uma grande quantidade de acessos

em seu catálogo de produtos e por consequência precisar de mais recursos
computacionais para segurar a carga, todas as outras funcionalidades, que
muitas vezes não precisariam ser escaladas, terão de escalar, pois tudo faz parte
de um único conjunto.
Em determinados casos essa necessidade pontual de escala por um recurso pode

fazer com que os custos com infraestrutura sejam elevados, pois claramente há
uma ineficiência técnica embutida no processo.
²https://www.gartner.com/en/information-technology/glossary/scalability
Em contrapartida, em determinadas situações, não é porque um sistema precisa

ser escalado por inteiro que seus custos serão mais elevados quando trabalhamos
com outro tipo de arquitetura, como a de microsserviços por exemplo. Temos
que ter em mente que quando trabalhamos com arquiteturas distribuídas, há
também outros custos inerentes a essa modalidade.
Débitos técnicos
É evidente que qualquer tipo de aplicação, independente da arquitetura a ser

utilizada em algum momento terá débitos técnicos, ou seja, pequenas melhorias,
refatorações, implementações que deveriam ser realizadas e que foram “deixadas
para depois”.
A medida em que os débitos técnicos se acumulam ao longo do tempo, a

instabilidade do sistema como um todo acaba aumentando, gerando assim uma
queda considerável na produtividade da manutenção e implementação de novos
recursos.
Quando trabalhamos com sistemas monolíticos, isto acaba sendo potencializado,

uma vez que há um alto acoplamento em todos os componentes da aplicação.
Por outro lado, isso não significa que pequenos sistemas não possuem ou não
possuirão débitos técnicos. Todavia, como a base de código é limitada, tais
débitos não terão tanta influência na solução como um todo.
Domain Driven Design
Introdução
O design orientado ao domínio, também conhecido como DDD (Domain Driven

Design) é uma abordagem que trabalha com práticas de design e desenvolvi-
mento, oferecendo ferramentas de modelagem tática e estratégica para entregar
um software de alta qualidade, acelerando o seu desenvolvimento e garantindo
sua sustentabilidade.
Alguns desenvolvedores acreditam que o DDD se resume a apenas uma série

de design patterns como agregados e repositórios, criando uma pasta de infra
para separar as camadas do nosso projeto, entre outros. Outros já veem o DDD
com mais abrangência. Mas, no fim das contas, também não conseguem explicar
claramente como isso funciona.
Isso tudo é muito estranho porque de fato o DDD parece complexo quando
nós consultamos as principais literaturas a respeito dele. E mesmo quando
pesquisamos, isso ainda nos deixa dúvidas sobre como nós podemos colocar isso
em prática no nosso dia a dia.
Nesse capítulo não vamos focar apenas nos aspectos práticos porque o DDD vai
Domain Driven Design 127
muito além disso. O seu foco é conhecer não apenas o ambiente, mas também
os contextos e as pessoas que trabalham em um projeto. E ainda, baseado nisso,
permitir uma separação que faça sentido para a organização em si.
Não basta começar diversos projetos e dizer que estamos aplicando o DDD em
tudo, sendo que no final das contas isso resulta em diversas pastas repetidas em
diversos projetos.
O intuito deste capítulo é fazer com que essa filosofia de trabalho mude a sua
forma de pensar em software, principalmente no seu trabalho com projetos de
grande porte. Normalmente não aplicamos isso em pequenos projetos porque
o DDD é fundamentalmente utilizado quando nós não temos clareza total do
projeto e suas áreas.
Uma palavra que resume bem o DDD é clareza. A clareza em um projeto

minimiza seus riscos em diversas perspectivas, principalmente quando o mesmo
deve perdurar por anos. Nós não podemos fazer um software que 6 meses se
tornará o famoso “legado” e que nenhuma pessoa desenvolvedora irá querer
mantê-lo.
O DDD é sem dúvidas um recurso que pode nos ajudar com esse objetivo e, com
a sua devida aplicação, desenvolver software se tornará mais divertido e com
menos riscos.
Ponto de partida no DDD
Agora iremos explorar a filosofia e os conceitos teóricos que estão por trás do
DDD, considerando que ao termos mais entendimento desses pontos, facilitará
o processo de aplicar DDD na prática.
Como o próprio nome sugere, o Domain Driven Design se refere a como

podemos desenhar o software guiado ao domínio, que é o coração da aplicação.
Não pense apenas sobre os design patterns, pastas dentro do seu projeto, entre
outros, porque o DDD foca muito mais em como modelar o software do que
desenvolvê-lo em si.
O DDD é uma forma de desenvolver o software focando no coração da aplicação,

o que nós chamamos de domínio. Seu objetivo é entender os contextos e regras
do projeto, seus procedimentos e complexidades, separando-as de outros pontos
complexos que são adicionados durante o processo de desenvolvimento.
O DDD surgiu de um autor chamado Eric Evans, de seu livro publicado em

meados de 2003.
É importante termos isso em mente porque o DDD é um assunto que oscila muito
durante os anos. Ora é muito falado, ora não. Atualmente, com a importância
dos microsserviços, o DDD também tem destaque porque o grande desafio de
trabalhar com microsserviços é modelar o software e os seus contextos.
Quando observamos o livro de Eric Evans, é notável que existe um lado filosófico
em torno dele, que chega ser até mais importante do que os padrões de projeto
que utilizamos em nosso dia a dia.
Essa filosofia parte de uma visão madura para que o desenvolvedor trabalhe em
seu projeto com orientação de trazer soluções para problemas complexos. Não
podemos ser inocentes ao ponto de ver um projeto e pensar somente no banco
de dados, cadastros, CRUDs, entre outros.
Trabalhar em torno dessa filosofia esclarece o quão é importante é entender e

modelar um software baseado em suas complexidades de negócio.
Foram através desses conceitos iniciais de Evans que surgiram entusiastas que
tiveram mais clareza nas falhas que existiam em seus grandes projetos.
Depois do lançamento do livro de “capa azul” (como assim é conhecido o

livro de Evans), houve uma série de lançamentos de outros livros que foram
imprescindíveis para que pudéssemos nos aprofundar na filosofia em torno do
DDD.
Entre os mais destacados está o livro de “capa vermelha” de um autor chamado

Vaughn Vernon. Este segundo livro é um pouco mais prático em relação ao livro
de Eric Evans.
Outro livro de Vernon para se aprofundar é o Domain Driven Design Distilled.

Ele é uma obra mais recente em relação as outras contendo um resumo sobre
o DDD. É um livro para se ler com cautela pois ele deixa algumas partes
importantes de fora.
A vantagem de ler esse livro são os tópicos que vão direto ao ponto, que
desmistificam grande parte do DDD de uma forma menos densa.
As complexidades de um software
Normalmente consideramos aplicar o DDD em projetos de software mais

complexos. Não faz sentido usar essa abordagem em um sistema típico de
estabelecimentos de pequeno porte, como uma “padaria”, que só vai vender um
único produto e receber o troco.
A complexidade de um software como a do exemplo anterior é tão pequena que

não há quase o que modelar. É um nível de complexidade tão simples que boa
parte dos softwares de empresas desse tipo são softwares de prateleira.
São softwares que podem ser adaptados a qualquer tipo de negócio sem custo-
mização.
O DDD é normalmente utilizado quando temos problemas maiores que nos

impedem de termos a clareza de como as áreas e pessoas de um projeto se
relacionam e se comunicam.
Quando trabalhamos com pessoas de diferentes departamentos, por exemplo,

nós percebemos que elas usam termos completamente diferentes entre as suas
respectivas áreas.
O DDD nos deixa claro de que em grandes projetos há muitas áreas, regras de
negócio e pessoas com diferentes visões da organização que estão situadas em
diferentes contextos.
Vamos usar como exemplo uma empresa que seu “core business” é fazer
cobranças de contas em aberto em nome de diversas corporações. Essa operação
envolve atendentes de telemarketing que usam um software de discagem auto-
mática. Se pensarmos bem, com certeza existe um diferencial na automatização
desses processos de cobrança em relação ao de uma empresa “tradicional”, que
liga para cobrar boletos bancários em aberto de seus clientes.
Isso acontece porque o coração do negócio da empresa de telemarketing é a

cobrança. Cobrar é a razão da empresa existir, logo, a modelagem de um pro-
blema de cobrança nesse caso torna-se muito mais complexo pois provavelmente
envolve seu diferencial competitivo no mercado.
Também, normalmente quando tratamos de empresas e seus diversos departa-

mentos, esses departamentos possuem a sua própria forma de se “expressar” e
falar do negócio utilizando certos jargões no dia a dia.
Os bancários, por exemplo, podem usar o termo ‘francesinha’, que é o nome que
eles dão para um tipo de relatório de quem realizou pagamentos. Mas quando
esse termo é mencionado para funcionários de outro departamento, isso pode
não fazer sentido nenhum.
Quando percebemos isso, é possível ter mais clareza para entender que o
software não é apenas uma simples unidade. Ele é feito de contextos, regras,
implementações que possuem objetivos diferentes.
Muitas vezes os softwares são independentes, sejam eles microsserviços ou

sistemas monolíticos. No fim das contas o software é vivo porque ele é movido
a pessoas que atuam em diferentes contextos e entender isso é crucial durante a
criação de uma modelagem para cada tipo de contexto.
Não é possível deixar de utilizar técnicas avançadas em projetos de alta com-

plexidade porque não podemos tratar de um software grande, que tem diversos
departamentos, complexidades e regras, de uma forma simplória. O software
precisa se adaptar a organização e não a organização ao software.
Em torno de uma solução há política, pessoal e cultura. Tudo isso deve ser
levado em consideração. Se não levarmos isso em conta, sem dúvidas o projeto
já fracassou em seu primeiro dia de desenvolvimento.
Seja qual for a sua experiência trabalhando em grandes projetos, você já deve
ter visto um projeto falhar devido a alguns pontos que foram citados até aqui.
É notável que grande parte da complexidade desse tipo de software não vem
da tecnologia; mas da comunicação e separação de contextos que envolvem o
negócio por diversos ângulos.
Nós perguntamos como as coisas devem ser feitas, seguindo as instruções que
nos foram dadas. E de repente o responsável pelo produto diz que quer um
resultado diferente.
Frequentemente alguns desenvolvedores são inocentes e recebem o feedback do

cliente dizendo que está tudo em ordem com o software, mas em outras reuniões
eles levam o que foi solicitado e descobrem que outro membro da equipe não
concorda com o que foi feito.
Como o DDD pode te ajudar
De forma geral o Domain Driven Design vai te ajudar a ter uma visão ampla
do problema a ser resolvido e a quebra-lo em problemas menores. Também
ele te dará técnicas de como minimizar ruídos de comunicação entre todos
os envolvidos, bem como trabalharmos com patterns que visam deixar nossas
aplicações cada vez mais desacopladas preservando ao máximo suas regras de
negócio.
Para que o DDD te ajude a entender os principais desafios de como desenvol-

ver software e suas complexidades geradas em torno de uma organização, é
importante que entendamos os pontos abaixo. Lembrando que todos eles serão
aprofundados durante nosso capítulo sobre DDD.
Resumindo
Nos tópicos anteriores, falamos sobre Domain Driven Design de maneira in-
trodutória, mas daqui para frente queremos explicar alguns aspectos essenciais
para compreensão do que realmente é o DDD. Porém, antes disso, precisamos

alinhar nossas expectativas em relação a este módulo. Digo isso, pois sabemos
que muitos devs querem entender o DDD passando direto para a prática, criando
várias pastas e organizando sua aplicação. Todavia, este tema é muito mais
profundo do que isso. Existem alguns conceitos teóricos que são extremamente
relevantes para que possamos realmente trabalhar com DDD.
Antes de explicarmos um pouco mais os aspectos que, de fato, fazem parte

do DDD, queremos parafrasear a fala de Vernon. Esse autor nos afirma que
falar de DDD diz muito sobre conseguir modelar de forma explícita uma
linguagem universal, isto é, uma linguagem ubíqua, dentro de um contexto
delimitado. Ou seja, basicamente, antes de usarmos o DDD, temos uma grande
confusão em nosso domínio. Então, começamos a entender um pouco melhor
o que está acontecendo depois que passamos a escutar as pessoas falando entre
seus diversos departamentos. Isso acontece porque conseguimos compreender
suas linguagens. Quando percebemos que essa linguagem muda, temos uma
sinalização de que o contexto mudou. E ao entendermos o contexto, conseguimos
delimitá-lo. Feito isso, podemos desenvolver um software para aquele “pedaço”,
especificando os jargões, as expressões, os nomes dos relatórios, as entidades e os
participantes do projeto. Eventualmente, esse contexto vai poder se comunicar
com outro, mas aquela confusão não existirá mais, pois teremos aquela clareza
que precisamos.
Assim, quando falamos em DDD é necessário entendermos como modelar as

linguagens, compreendendo seus contextos. Desse modo, trabalharemos cada

um dos seus pontos principais.
Domínio
O domínio, ou “domain”, é a razão pelo qual o software existe. Em outras

palavras, é o coração do software. E esse conceito por si já define que nós temos
um desafio para resolver.
Se não entendermos o real objetivo pelo qual o software será desenvolvido,

a batalha já está perdida. Normalmente quando recebemos o “problema” do
cliente, tal problema é apenas a ponta do iceberg. Precisamos mergulhar a fundo,
entender mais sobre a organização, suas áreas, e as intenções reais por de trás
da solução a ser desenvolvida.
Subdomínios
O grande desafio é que normalmente o problema a ser resolvido é muito grande,

e nesse ponto, de forma inevitável, precisamos dividi-lo em partes menores.
Essas partes são chamadas de subdomínios. Diferente do domínio, que acaba
se tornando uma visão geral do problema, os subdomínios acabam cobrindo
detalhes finos que nos ajudam a ter um pouco mais de clareza sobre o coração
da aplicação.
Linguagem universal
O DDD também estabelece uma linguagem universal entre todos os que estão
envolvidos no projeto. A “Ubiquitous Language”, ou Linguagem Ubíqua, é um
termo recorrente em qualquer livro sobre DDD.
Vamos pensar no exemplo da francesinha na área bancária (extrato de movi-

mentação de títulos). Não adianta criarmos um sistema com o menu chamado
“relatório de contas pagas”, pois todos naquele departamento ficarão procurando
por “francesinha”, considerando que ela segue um jargão popular naquele
contexto.
Todo esse problema ocorre porque nós não conseguimos ter uma única lin-
guagem universal dentro da empresa. Por mais estranho que pareça, você vai
perceber que a empresa é composta por uma cultura que é modificada e adaptada
aos poucos dentro de cada departamento.
E como cada área tem o seu próprio jargão, para um funcionário na área de
vendas pode existir um cadastro de clientes que fecharam contratos com ele.
Já no departamento de de compras também existe uma área para cadastro de
clientes, porém nesse caso o cliente é a própria empresa, pois ela possui diversas
filiais.
Perceba que em um departamento o cliente é chamado de uma forma, mas

dentro de um setor diferente a palavra “cliente” já possui outro significado. Esses
departamentos podem usar a mesma palavra e, caso se comuniquem, o cliente

vai representar uma coisa completamente diferente.
Por isso é importante entender, mapear e extrair essa linguagem universal para
esclarecer e minimizar os principais ruídos de comunicação.
Design estratégico e tático
Um dos objetivos do DDD é nos ajudar a criarmos o design estratégico e tático

para a modelagem de nossas aplicações.
Isso significa que através da clareza da existência de um domínio e seus diversos

subdomínios, podemos criar a modelagem estratégica delimitando contextos
e seus relacionamentos. Normalmente tal modelagem é chamada de “Context
Map” ou mapa de contexto.
Além disso, precisamos de um design tático para mapearmos agregados, entida-

des, objetos de valor, entre outros, facilitando assim o processo de codificação
do sistema.
Agora que tivemos uma idéia geral sobre DDD, a seguir entenderemos os
princípios básicos relacionados aos domínios e subdomínios como elementos
fundamentais do Domain Driven Design.
Delimitação
O domínio é parte essencial do DDD, considerando que o design guiado ao

domínio se refere objetivamente ao coração da aplicação. Entender o domínio é
ter entendimento sobre as áreas que envolvem o negócio; e assim que reconhece-
mos isso nós podemos dividir tal domínio em partes menores, conhecidas como
subdomínios.
Delimitar um domínio nos possibilita pensar na solução em torno de toda

a complexidade do negócio. Existem, porém, diversos tipos de problemas e
complexidades que são partes importantes para o software.
Na própria literatura do DDD existe um exemplo que trata a exploração do nosso

domínio como se estivéssemos entrando num quarto escuro segurando apenas
uma lanterna. Nós só conseguimos enxergar algumas partes do cômodo quando
ligamos a lanterna. O mesmo acontece quando começamos a explorar os nossos
domínios e subdomínios porque inicialmente nós não temos a visão de um todo.
E é assim que conseguimos ver, nós percebemos que existem partes que nós
podemos separar e é por isso que essas partes são chamadas de subdomínios.
Mas na separação dos subdomínios também percebemos que eles possuem graus
diferentes de importância para o negócio.
Domínio principal ou “Core Domain”
Quando identificamos e separamos a parte mais importante desse negócio nós

temos então o nosso Core Domain, ou seja, o nosso domínio principal. Caso
ele não existisse não haveria sentido para todo o restante existir. Seria como a
Netflix sem filmes e séries ou uma fábrica de automóveis que não tem carros.
Por outro ângulo, ainda observando através da nossa lanterna, nós também
temos alguns pontos importantes para definir.
O Core Domain é o coração do negócio e também o diferencial competitivo da

empresa. Normalmente quando pensamos em domínio, isso também compõe
o diferencial de toda a concorrência. Se não houvesse diferencial e toda a
complexidade fosse banal, nós simplesmente usaríamos softwares de prateleira.
Domínios de Suporte
Diferente do Core Domain, também existe o que chamamos de domínio de

suporte. Eles apoiam o domínio principal no dia a dia e apesar de não ser o do-
mínio principal, eles auxiliam o negócio a possuir seus diferenciais competitivos
e garantir que tudo funcione plenamente.
Se tivermos um e-commerce, por exemplo, precisaremos de produtos, uma loja

e a parte de checkout. Vamos ter também o centro de distribuição.
Não podemos pensar em e-commerce sem um centro de distribuição, porque,

nesse contexto, isso pode ser perfeitamente um dos diferenciais da empresa, pois
afeta diretamente na velocidade de entrega dos produtos vendidos. Nesse caso,
poderíamos considerar o centro de distribuição como um subdomínio de suporte,
pois ele viabiliza a operação do domínio principal.
Domínios e Subdomínios Genéricos
Os subdomínios genéricos dão apoio a todo o sistema, mas geralmente não

agregam tanto diferencial competitivo para a empresa. E vale mencionar que
algumas empresas usam com frequência “softwares de prateleira” como parte
de seus subdomínios genéricos.
Contudo, se você observar, esses “softwares de prateleira” ajudam na rotina da

empresa, porém normalmente são facilmente substituíveis.
Espaço do problema vs espaço da solução
Sabemos que o DDD está relacionado à tentativa de resolver um problema, isto

é, quando utilizamos esse recurso pensamos em um problema e em como tratá-
lo, para depois resolvê-lo. Desse modo, podemos dizer que, ao desenvolvermos
uma solução, temos um espaço de problema e um de solução. Assim, é impor-
tante entendermos a relação entre essas áreas, entre os subdomínios e outros
elementos.
Primeiramente, vamos imaginar que temos um quadrado chamado de “espaço

problema”. Podemos defini-lo como uma visão geral do domínio e suas complexi-
dades. Logo, quando temos algo para resolver, começamos com uma ideia geral
do que precisamos fazer. Em seguida, entendemos as principais complexidades
do que precisamos trabalhar. Depois disso, podemos separar esse domínio maior
em subdomínios, ainda nesse “espaço problema”. Quando temos um subdomínio
e uma ideia geral do que está acontecendo, saberemos qual dificuldade vamos
enfrentar.
Por outro lado, vamos imaginar que temos outro quadrado. Neste segundo,
poderemos entender o problema e organizá-lo para que possamos encontrar
possíveis soluções. Chamaremos este segundo ambiente de espaço da solução.
Assim, podemos separar o domínio e suas complexidades para fazermos a
modelagem desse domínio. Então, se no espaço do problema temos o domínio de
forma geral, no espaço da solução temos tudo para resolvê-lo. Lembrando que, ao
falarmos sobre DDD, um dos grandes pilares é conseguir fazer essa modelagem
de domínio. Pois o domínio é o problema do negócio e a solução é conseguir
modelar esse domínio para desenvolver a aplicação de maneira sustentável.
Assim, quando falamos em “problema vs solução” nos referimos a esse processo

todo: de modelar, de separar e de transformar os subdomínios em contextos
delimitados. Dessa maneira, conseguimos “atacar” o software bem no seu
coração. E partindo disso, começaremos a perceber que grande parte do que
fazemos com DDD é trabalhar exatamente nesses contextos delimitados.
Contexto delimitado
Ao separarmos os problemas em subdomínios, para solucioná-los, precisamos

delimitá-los. Cada contexto delimitado vira um subproduto que teremos que
resolver e trabalhar. Basicamente, veremos um problema e começaremos a
modelá-lo, ou seja, iremos separá-lo em partes menores e as delimitaremos
em pontos que servirão para começarmos a nos organizar. Feito isso, podemos
desenvolver no espaço da solução. Desse modo, temos o domínio modelado e os
contextos delimitados. Assim, conseguimos entender o que precisamos fazer, e
qual é a prioridade para cada área.
Então, todas as vezes que começamos a falar sobre DDD, estamos fazendo
uma exploração do domínio para conseguirmos iniciar sua modelagem. Essa
modelagem, no final das contas, sempre será o entendimento do problema do
subdomínio. Normalmente esses subdomínios vão se tornar contextos delimita-
dos, isto é, será o local que verificaremos os problemas específicos para resolvê-
los.
O que é contexto delimitado?
Antes de prosseguirmos com nossos estudos, é importante sabermos que a

grande maioria das literaturas sobre o DDD está presente em livros, e materiais,
da língua inglesa. Logo, ao fazermos buscas teremos resultados melhores se usar-
mos terminologias em inglês. Assim, é essencial sabermos que a terminologia
usada para contexto delimitado, em inglês, é “bounded contexts”. Sabermos isso,

como já dissemos, é interessante para que nossas pesquisas sejam mais eficazes.
Para definir o que, de fato, é o contexto delimitado e sua importância dentro do

nosso processo, vamos utilizar a definição de Vernon. Ele nos diz que bounded
contexts é uma divisão explícita dentro de um domínio, isto é, dentro de um
modelo de domínio. Um bounded pode ser considerado uma fronteira, ou
seja, um limite. Então, quando falamos em contexto delimitado significa que
temos uma divisão explícita de uma parte específica do domínio que estamos
modelando. Apesar disso fazer muito sentido, falar pode parecer, de certo modo,
muito genérico, por isso Vernon nos fala algumas formas para conseguir fazer
essa delimitação. Uma delas é por meio da linguagem de termos e frases que
são utilizados como dentro da comunicação de determinados contextos. Nesse
caso, usamos os estudos relacionados à linguagem ubíqua, também conhecida
como linguagem universal ou onipresente. Assim, tudo que é específico daquele
negócio, desde a forma como as pessoas se comunicam, até a forma como
os problemas são resolvidos, será considerado para fazermos a delimitação do
contexto.
Perceberemos, ao longo de nossos estudos, que dentro de um negócio um dos

“ingredientes” mais fortes é a linguagem. Quando notarmos todas as pessoas
falando a mesma língua, provavelmente elas farão parte do mesmo contexto.
Quando esse linguajar começar a mudar, teremos o indício de que estamos
cruzando a fronteira e entrando em outro contexto delimitado. Ou seja, a
linguagem que é utilizada dentro do modelo é um dos grandes indícios que nos
possibilita perceber em qual contexto estamos.
Com esses conceitos iniciais, já conseguimos perceber que raramente fará

sentido trabalharmos utilizando o DDD em um sistema de “padaria”, por
exemplo. Isso porque, o contexto desse sistema é tão pequeno que todos já
falam a mesma língua. Então, não faz sentido modelarmos o seu domínio por
ser algo pequeno. Fora isso, sabemos que esses sistemas não são complexos.
Todavia, seria diferente se tivéssemos um negócio de uma “padaria industrial”.
Neste segundo caso, teríamos diferentes fornecedores e diversas funções, isto é,
diversos departamentos com linguagens próprias em cada setor.
Contexto é rei
Quando conseguimos compreender o que é um contexto, é mais fácil enten-

dermos como as delimitações ocorrem. Podemos usar a regra do “contexto é
rei” para fazermos essa definição. Tal regra nos diz que o contexto sempre vai
determinar os mais diversos aspectos no processo de desenvolvimento de uma
solução. Por exemplo, determinará qual área da empresa trabalharemos, o tipo de
problema que iremos resolver e, essencialmente, a linguagem que será utilizada
naquele contexto.
Para compreendermos como isso funciona de maneira prática, podemos imagi-

nar a seguinte situação: temos dois contextos delimitados chamados de “ticket”.
Estes têm uma aplicação sendo modelada entre eles, isto é, no meio deles. O
primeiro ticket está em um subdomínio denominado de “venda de ingresso”. E

dentro dessa área temos o ticket emitido para venda. Por outro lado, o segundo
ticket está em um subdomínio chamado de “suporte ao cliente”. Observamos que,
neste caso, temos duas palavras exatamente iguais, mas que estão representando
significados diferentes. Isso significa que, claramente, estaremos em contextos
delimitados diferentes. Assim, é evidente que no primeiro caso queremos falar
sobre vendas e no segundo sobre um suporte dado ao cliente, mas ambos são
escritos como “ticket”. Ainda com esse exemplo, vamos imaginar que estamos
desenvolvendo um sistema monolítico. Logo, precisamos criar a entidade ticket.
Lembre-se que teremos o ticket da venda de ingresso e o de suporte. Desse modo,
precisaremos criar entidades diferentes para fazer uma separação e modularizar
o sistema (criar áreas diferentes e adaptar o sistema). Isso porque o nosso sistema
tem que trabalhar baseado em contextos, pois se não fizermos dessa maneira
teremos uma entidade chamada “ticket” com pontos extremamente diferentes.
Então, o contexto sempre vai ser rei. E quando temos a mesma palavra com
significado diferentes, provavelmente estamos em contextos diferentes.
De modo semelhante, quando temos duas palavras diferentes, porém, com

mesmo significado, provavelmente estaremos em contextos diferentes. Por exem-
plo, a história da “francesinha” do banco. Digamos que a área da contabilidade
utiliza a entidade “relatório de boletos pagos”, mas na área dos bancários
que estão na agência, chamam isso de “francesinhas”. Sabemos que os dois
representam a mesma coisa, assim, é bem provável que essas palavras estejam
em contextos diferentes.
É importante sabermos que em algum momento palavras iguais com significados

diferentes, ou palavras diferentes com significados iguais, precisam “conversar”.
Por isso, no próximo tópico falaremos um pouco sobre como essas relações
podem acontecer.
Elementos transversais
É comum que as diferentes áreas de uma solução estabeleçam algum tipo de

relação, apesar de existir uma delimitação entre elas. Isso acontece de modo
transversal, quando as entidades, de todos os lados, conversam, mesmo tendo
perspectivas diferentes.
Por exemplo, vamos imaginar que temos um “cliente” que está em duas áreas:
na área de vendas de ingresso e na área de suporte ao cliente. Nesse caso,
teremos o mesmo cliente em contextos diferentes. Mas é possível percebermos
uma correlação entre essas áreas. Quando trabalhamos com cliente em venda
de ingressos, estamos preocupados com o evento, com o ticket local e com o
vendedor. Por outro lado, quando trabalhamos com cliente na área de suporte,
estamos preocupados com o departamento que vai ser atribuído para dar o
suporte, com o responsável pelo retorno ao cliente, com o ticket e com as
dúvidas dos clientes. Assim, podemos perceber o quanto a perspectiva muda
quando mudamos de contexto. Isso pode gerar uma confusão enorme na cabeça
das pessoas que vão desenvolver a solução. Pois nós, desenvolvedores, temos a
tendência de pensar que tudo é a mesma coisa, com a mesma perspectiva. Isto é,
geralmente percebemos tudo de modo unilateral.
Ainda com o exemplo da palavra cliente, imagine que precisaremos modelar uma
entidade. Primeiro criamos uma classe de clientes, então vamos criar o ID e o
nome do cliente. Depois disso, vemos que o cliente vai poder comprar ingressos.
Logo, colocamos da seguinte forma no código, “ticket: locais que esse cliente
comprou, vendedores que já venderam para ele, os eventos que esse cliente já
fez” . Deste modo, modelamos a área de vendas. Porém, ao percebermos que
esse cliente pode ter ticket de suporte podemos colocar “ticket: a dúvida que o
cliente abriu, departamentos que colaboraram para ele e quais os responsáveis
pelo suporte dado ao cliente”. É possível percebermos que a classe de cliente
ficou enorme, pois ela está tentando atender diversos contextos onde o cliente
existe. Podemos concluir, então, que isso é uma “loucura” já que o cliente pode
participar de diversos contextos. Imagine a pessoa desenvolvedora ter que criar
apenas um arquivo para modelar tudo isso como uma coisa só.
Assim, quando temos contextos diferentes, mesmo que a entidade seja a mesma,
precisamos modelá-la de acordo com aquele contexto. Devemos fazer isso
mesmo em um sistema monolítico, pois se não delimitarmos a aplicação, nosso
arquivo irá virar um “monstro”. Então, mesmo que tenhamos um único cliente, é
extremamente necessário nos atentarmos a essas delimitações, pois caso precise
quebrar a solução em microsserviços teremos que reescrever tudo, por termos
uma única classe que está servindo para todos os lados do sistema. Ter essa ideia
de perspectivas diferentes faz muita diferença ao desenvolvermos um sistema.
Podemos colocar essas ideias, até aqui teóricas, em prática através de um mape-
amento de contexto. Com esse recurso, fazemos uma modelagem estratégica das
parte do domínio de nossa aplicação. Dedicaremos um tópico para explicarmos
como isso funciona.
Visão estratégica
Quando modelamos um software é necessário termos uma visão estratégica de

como as coisas estão se encaixando. Podemos fazer isso destacando aspectos de
um espaço problema.
Sabemos que buscamos entender o domínio de forma geral. Assim, conseguimos

separar os aspectos em partes (áreas) para depois convertê-las em delimitação
de contextos. Porém, não podemos nos esquecer que esses contextos invaria-
velmente irão conversar., ou seja, eles irão se complementar e, eventualmente,
um vai servir ao outro. Logo, nesse ponto, precisamos ter uma visão estratégica,
ainda que, num primeiro momento, seja de forma superficial. O olhar estratégico
é exatamente esse que falamos anteriormente, a visão geral da solução e
de como as partes poderão conversar. Dessa maneira, saberemos, inclusive,
como organizar o time durante todo o processo de modelagem, organização e
desenvolvimento do software. Precisamos entender como criar uma modelagem
estratégica para ter uma visão mais de cima.
Por meio de um context map podemos conseguir ter essa visão. Isso acontece
pois, utilizando esse recurso, conseguimos mapear nossos contextos e, desse
modo, teremos uma compreensão mais clara de como os relacionamentos entre

as áreas de uma aplicação acontecem.
Context mapping na prática
Fazer um context mapping é uma forma de modelar estrategicamente um

software. Este é um mapeamento que nos permite visualizar como acontecem
as relações entre os contextos de um sistema.
Para entendermos como isso funciona na prática, vamos imaginar que temos
um ambiente de um negócio de vendas onde colocaremos todos os nossos
contextos. Neste ambiente, teremos a modelagem do nosso domínio com seus
contextos delimitados. Podemos deduzir que o “core business” é a área de venda
de ingressos online. Mas, além dessa área, teremos também a de suporte ao
cliente, a de vendas de ingressos offline (através de parceiros) e a de pagamentos.
É importante dizermos, antes de prosseguirmos com o exemplo, que a área de
vendas online tem peso diferente da área de vendas offline para o negócio. A
primeira seria responsável por 80% do funcionamento do negócio. A segunda
seria algo extra, fruto da parceria com shoppings, lojas, casas noturnas, etc.
Porém, as duas são partes essenciais para o funcionamento do negócio.
Continuando com nosso exemplo, podemos imaginar esses quatro contextos

delimitados bem claros: vendas online, vendas offline, suporte ao cliente e
pagamento. E dependendo da organização da empresa, podemos criar um time
para cada um desses contextos. Esses times irão falar e se organizar de maneira
específica para que cada um consiga atender as necessidades de seus próprios

departamentos. Em alguns casos, é possível que haja a necessidade de termos um
domain experts para nos auxiliar na resolução de problemas específicos daquela
área.
Tanto a área de vendas de ingressos online quanto a de vendas offline tem um

modelo de parceria. Isso porque ambas fazem o que a empresa precisa para
se manter no mercado, isto é, elas exercem a principal função da corporação.
Obviamente, uma é mais o core business do negócio do que a outra. Porém,
mesmo que a venda offline seja uma segunda fonte de receita, ainda assim
essas duas áreas precisam vender. Dessa forma, provavelmente, precisam estar
integradas ao mesmo sistema. Chamamos a relação que acontece entre esses
dois contextos de partnership. O que significa que esses dois times trabalham
em conjunto para que o resultado seja satisfatório para os dois.
Então, ao vendermos ingressos online, criamos uma API para que o sistema do
shopping possa consumir. Mas o sistema de vendas online também irá consumir
a API de quem está vendendo offline. Logo, podemos dizer que, nessa parceria,
um contexto consome do outro.
Em algumas situações é possível criarmos uma espécie de núcleo compartilhado.

Porém, caso nosso projeto seja grande, isso pode acabar gerando diversos
problemas. Por exemplo dificuldades relacionadas ao time ou à manutenção do
sistema, pois um contexto afeta diretamente o outro.
Inicialmente a criação de um Sidecar para que a geração de ingressos seja

facilitada pode soar como uma boa ideia. Mas na prática é possível que não
funcione como esperado. Ainda assim, podemos ter uma relação entre esses dois
contextos, pois essas áreas podem dividir ou criar um núcleo de sistema que os
dois possam usar. Então, dizemos que essa parceria é uma forma de conexão
entre um contexto e outro. Pois é através desse núcleo compartilhado que esses
contextos fazem as mesmas ações
Além dessa relação de parceria, temos a relação entre cliente e fornecedor,

porque a área de vendas de ingresso online vai precisar realizar pagamentos no
momento da emissão da venda. Isto é, uma relação em que um contexto vai for-
necer um serviço para o outro. Assim, este outro conseguirá realizar a transação
necessária naquele momento. Como vimos neste exemplo, a área de pagamento
vai oferecer um serviço para área de vendas de ingressos. Então podemos dizer
que, nessa relação, vendas de ingressos é o cliente e a área de pagamentos é o
fornecedor. Quando isso acontece, conseguimos criar uma relação de upstream
e downstream. O primeiro vai fornecer o serviço e, consequentemente, vai ditar
as regras do serviço implantado. Por exemplo: todas as vezes que a área de
pagamento fizer uma melhoria, como adicionar uma nova parceria, vai informar
para a área de vendas que, em tese, terá que se adaptar para que a área de
pagamento funcione adequadamente e, assim, essas áreas consigam trabalhar
de forma conjunta. Logo, dizemos que o downstream, que é o cliente, vai se
adaptar para conseguir consumir algo do upstream.
O suporte ao cliente também pode ter uma relação de cliente e fornecedor, onde
a área de vendas de ingressos (em que os clientes são gerados) pode fornecer
informações para que a área de suporte ao cliente funcione. Desse modo, a área
de vendas pode ser um upstream e a área de suporte um downstream. Isso vai
depender de como a solução está sendo modelada.
É importante dizermos que não há uma regra específica que diga o certo e o
errado em relação a esse tema, pois tudo vai depender muito de como a empresa
funciona. Por exemplo, se a área de vendas usar a de suporte, teríamos uma
situação invertida em relação à que apresentamos anteriormente. Então tudo
depende de como vai ser a dinâmica do negócio. O que precisamos compreender
é que pode existir relações de parceria, chamada de shared partnership, assim
como pode existir também relações cliente e fornecedor entre os contextos.
Além disso, podemos utilizar um módulo para o serviço de pagamento, como

uma API Gateway. Por ser um serviço externo, um gateway está em outro
contexto, o que é perfeitamente aceitável. Por exemplo: podemos imaginar que
essa área de pagamento vai usar uma Gateway chamada XPTO, que tem uma
forma própria de trabalhar e sua API definida. Então essa Gateway vai ser o
fornecedor e a área de pagamento vai consumir tudo isso. Nesse caso, a Gateway
vai impor a maneira que a área de pagamento vai trabalhar, independente do
que nós, desenvolvedores, queremos. De forma prática, imagine que teremos
que trabalhar com o Banco Itaú, utilizando seus serviços de cartão de crédito
para fazer cobranças. Dificilmente pediremos para que esse banco faça alterações
em seu sistema por nossa API trabalhar de modo diferente. O mais provável é
que tenhamos uma relação conformista com uma empresa desse porte, a não
ser que sejamos tão grandes quanto o Itaú. Neste caso, podemos conversar com
o banco para que eles criem algo personalizado que nos atenda. Assim, dessa
última maneira, a relação não será conformista.
Outro exemplo de como as relações entre diferentes contextos acontecem é o

fornecimento de vídeos em streaming. Não podemos mudar a maneira como
um provedor irá distribuir nosso vídeo. Mas podemos dizer que temos algumas
exceções, como a Netflix. Empresas desse porte conseguem ter mais personifi-
cação por parte do provedor para atender suas necessidades. Então, reforçamos
que a maneira como essas relações acontecem depende muito da empresa, do
contexto, etc.
É perceptível que, quanto mais conformista é essa relação, temos tendência a nos
amarrar em outro sistema. Por exemplo, se usamos um sistema CRM de terceiros,
quanto mais o utilizamos, mais informações nossas esse sistema possui. É uma
relação conformista e raramente o modo de trabalho poderá ser alterado com
facilidade.
Eventualmente, em situações como a desse último exemplo, podemos fazer uma

camada anticorrupção. A ACL é uma camada de interface que fica entre o nosso
contexto e a gateway de pagamento. Caso precisemos mudar de gateway basta
trocar o código da camada de anticorrupção. Assim, não precisamos alterar o
código da parte lógica da área de pagamento em nossa aplicação. Então, funciona
como se fosse um adaptador que nos ajuda a minimizar esse problema que
vem dos relacionamentos conformistas, pois uma vez que temos uma camada
anticorrupção, ficará mais fácil conseguirmos realizar trocas de fornecedores.
Desse modo, o context mapping vai nos auxiliar a entender os relacionamentos

entre os contextos e os times de uma solução. Além disso, através dele consegui-
remos visualizar qual time fornece para qual time e quais trabalham em parceria.
Isso possibilita que tenhamos uma visão mais clara e estratégica da aplicação
(do negócio), algo extremamente importante, principalmente quando temos um
sistema de grande porte.
Padrões e starter kit
É importante conhecermos diversos padrões de relações entre contextos para

trabalharmos com context map. Por isso, neste tópico, nos dedicaremos a mostrar
alguns desses padrões e, além disso, falaremos sobre um projeto que alguns
desenvolvedores fizeram no Github.
Então, ao mapearmos um software é importante conhecermos os padrões que

são utilizados nas relações entre as áreas da aplicação. Por exemplo: o padrão de
Partnership, estabelecido por meio de uma parceria entre as áreas; o de Shared
kernel, quando mantemos uma biblioteca para algo compartilhado entre os
times; o Customer-Supplier Development, uma relação entre cliente e fornecedor
(um faz o consumo do outro, ou seja, upstream e downstream); a relação
conformista, em que há uma conformidade de uma das partes e o ACL, uma

camada de adaptação de interfaces que evita ficarmos presos em outro sistema.
Fora esses padrões, temos outros exemplos como, o Open host service, um
padrão em que um contexto vai fornecer um serviço que estará disponível
com determinado protocolo, como um GRPC; o Published language, onde a
linguagem faz total diferença na hora que vamos nos comunicar; o separate
ways, em que os contextos delimitados não vão mais se comunicar e cada um
mantém seu próprio padrão como também o Big Ball of mud, um sistema muito
comentado em livros por ter várias coisas misturadas e, por isso, torna-se comum
termos que lidar com ele no dia a dia.
Por vezes, é possível que esses nomes tragam algum tipo de complicação nas
relações, principalmente quando vamos fazer um contexto mapping. Então,
gostaríamos de indicar um projeto no Github chamado de DDD Crew. Você
pode acessá-lo aqui: https://github.com/ddd-crew/context-mapping
Dentro desse projeto, na parte de context map, conseguimos ver uma cheat sheet,
exemplos de diversos padrões com uma imagem representando cada tipo de
relação. Por exemplo, temos uma imagem que nos mostra o resumo do que é o
Open Host Service, isto é, um Bounded Context que oferece a definição de uma
série de serviços que serão expostos para outros sistemas. Além dessa imagem,
vemos uma que resume o customer/supplier, em que o primeiro é o downstream
e o segundo é o upstream. Assim, conseguimos ver a explicação de cada um dos
padrões.
Podemos ver também, mais abaixo, quais são os tipos de relações, por exemplo
se os contextos são mutuamente dependentes, se são free ou upstream e
downstream.
Além disso, nesse site temos a possibilidade de acessar uma versão read only
para utilizarmos no Miro. Assim, podemos criar novos documentos e utilizar
todos os padrões para fazermos o mapeamento de nossos próprios projetos.
Arquitetura Hexagonal
Introdução à Arquitetura Hexagonal
Neste capítulo veremos alguns conceitos relacionados à Arquitetura Hexagonal.

Com essas informações teremos uma visão mais clara na hora de programar
nossas aplicações. Isso faz com que o processo de desenvolvimento de softwares
de qualidade seja realizado de maneira mais fácil.
Por exemplo, imagine que precisamos desenvolver um sistema para um banco,

que oferece serviços de empréstimos aos seus clientes. Baseado nos dados das
pessoas, ele verifica o Score para calcular qual taxa de juros será cobrada para
cada empréstimo realizado. Na hora de desenvolver a solução, é importante
sabermos qual a melhor maneira de escrever esse processo. Antes de tudo,
precisamos entender o problema que devemos solucionar para a empresa. Neste
exemplo, é necessário encontrarmos a maneira mais adequada de calcular a taxa
de juros do empréstimo para cada cliente. Tendo o problema claro, seguiremos
para os próximos passos de uma programação: escolher uns frameworks, mode-
lar o banco de dados, fazer uma API Rest e, assim, fazer os cálculos. Podemos
dizer que esta é a maneira como costumamos desenvolver uma aplicação de
Arquitetura Hexagonal 158
forma geral. Fazemos tudo baseado na frase “nossa função, como dev, é resolver
problemas através do código”. De certo modo, podemos afirmar que essa frase
é muito “rasa” para descrever nossa função, porque existe muita complexidade
quando desenvolvemos um sistema. Inicialmente até teremos uma complexidade
de negócio, isto é, relacionada diretamente ao problema que estamos sendo
pagos para desenvolver, mas a criação de um sistema envolve também as
complexidades técnicas que nós mesmos adicionamos para resolver o negócio.
Entretanto, é possível afirmarmos que o problema de negócio é essa complexi-
dade que dizemos ser inevitável, pois estamos sendo pagos especificamente para
resolvê-la. Por outro lado, não devemos misturá-la com a complexidade técnica.
Dizemos que essa complexidade são os aparatos técnicos que iremos utilizar para
resolver o problema do negócio. Então, conseguimos perceber claramente que
existem duas complexidades quando vamos desenvolver uma solução. Temos a
complexidade de negócio e a técnica. Quando temos clareza sobre a existência
desses dois tipos de complexidades, nosso trabalho flui de maneira mais tran-
quila. Por exemplo, é comum misturarmos regras de negócio, banco de dados,
forma de comunicação etc. por não sabermos com qual complexidade estamos
trabalhando ao digitar determinado arquivo. Fazendo isso, nós esquecemos
que nossa principal função é proteger o negócio. Isso porque, colocar limites
muito claros entre as complexidades evita que a complexidade técnica invada o
negócio.
Se conseguirmos fazer essa separação, podemos trocar, conforme necessidade,

essa complexidade técnica. Por exemplo, um framework por outro ou um sistema
de cache por um protocolo diferente do HTTP. Tal possibilidade nos ajuda a

manter nossa aplicação coesa.
A separação de complexidades, faz com que a complexidade técnica seja uti-

lizada apenas para acessar o negócio. Assim, teremos um software totalmente
autocontido, com responsabilidades claras e facilmente portável (podemos mu-
dar um framework, um banco de dados e a forma de se comunicar). Com esses
conceitos em mente, sempre que formos digitar um código, podemos pensar e
raciocinar se naquele momento estamos trabalhando com complexidade técnica
(que nós adicionamos), ou se estamos trabalhando com complexidade de negócio
(que é o que realmente temos que resolver).
Ainda neste capítulo, nossos estudos serão direcionados para que possamos
compreender cada uma dessas complexidades. Pois quando trabalhamos com
arquitetura hexagonal, naturalmente separamos o negócio do técnico. Fora isso,
veremos também que essa breve introdução foi necessária para que nossa com-
preensão seja melhor quando falarmos, especificamente, sobre essa arquitetura.
A importância da Arquitetura de Software
A arquitetura hexagonal, também conhecida como “Ports and Adapters”, traz

conceitos extremamente importantes para conseguirmos desenvolver softwares
de qualidade. Isso porque, as ideias relacionadas a essa arquitetura podem nos
auxiliar no processo de desenho da aplicação.
Antes de prosseguirmos nesse assunto, é interessante conhecermos alguns

pontos importantes sobre arquitetura de software de modo geral. Quando
desenvolvemos um sistema, alguns aspectos fazem com que seja necessário
trabalharmos com arquitetura. Um deles é o crescimento sustentável da apli-
cação. Ou seja, conforme nós desenvolvemos o software, podemos melhorá-
lo sem a necessidade de muitos retrabalho ao longo do tempo. Assim, nossa
aplicação tem poucos débitos técnicos nesse processo. E, desse modo, ela pode
gerar valor e “se pagar” para os seus investidores ao longo do tempo. Sabemos
que, hoje em dia, é muito comum precisarmos refazer o software antes mesmo
da empresa terminar de pagar por ele. Então, a organização precisa fazer novos
investimentos para desenhar e desenvolver “tudo do zero”, antes mesmo de ter
o retorno financeiro que foi investido inicialmente. Mesmo que isso seja algo
comum, devemos estudar meios que evitem prejuízo para os clientes.
A arquitetura de software está diretamente relacionada aos limites que um

sistema precisa ter para garantir o seu crescimento sustentável. Ao arquitetar
uma solução conseguimos manter a qualidade daquilo que está sendo produzido,
para que gere o resultado esperado pela pessoa que investiu nessa aplicação.
Além de nos ajudar com a sustentabilidade da aplicação, os conceitos de

arquitetura nos auxiliam a entregar um software que não seja orientado a
framework. Isso significa que uma biblioteca não conduzirá a maneira que
iremos escrever nosso sistema.
Essa prática é considerada um problema justamente pela dependência que

teremos ao estar “plugados” em um determinado framework. Quando essa

dependência acontece não pensamos mais no problema do negócio, mas sim em
como o framework vai resolver outras situações técnicas. Então, lembre-se das
complexidades que falamos no tópico anterior. A complexidade de negócio não
pode estar atrelada à complexidade técnica de nossas bibliotecas/frameworks.
Se misturarmos as complexidades fazendo com que o framework resolva o
problema do negócio, algo pode estar errado em nosso modo de desenvolver
a aplicação.
Uma vez que arquitetamos nosso software, temos como resultado a criação de
um “lego”, isso mesmo quando fazemos uma arquitetura mais abrangente, como
microsserviços; ou quando trabalhamos pontos mais específicos de design do
software. Quando as partes do nosso sistemas são “legos”, conseguimos trocá-
las sem quebrar a estrutura desse software. Mas isso só é possível se tivermos
uma aplicação bem desenhada.
Então, podemos dizer que a arquitetura está relacionada ao futuro do software.

Pois ao arquitetar um sistema pensamos nele funcionando perfeitamente depois
de vários anos no ar. Porém, para que isso seja possível não podemos desenvolver
apenas um CRUD, algo que qualquer dev faz. Hoje em dia, por termos várias
ferramentas capazes de gerar esses CRUDs, é comum que os devs pensem
automaticamente em fazer apenas isso. Quando recebemos a solicitação para
pensar na modelagem de dados a cultura de criar apenas CRUDs nos impulsiona
a pensar em modelarmos o banco de dados antes mesmo de saber como iremos
trabalhar para resolver determinadas complexidades do escopo do software.

Todavia, é importante termos em mente que desenvolver um sistema vai muito
além de fazer esses CRUDs. Isto é, exige um entendimento do problema e um
desenho bem estruturado de toda a aplicação.
Ciclo de vida de um projeto
Um projeto de software tem diversas fases em seu ciclo de vida. Nos próximos
tópicos, iremos descrever dez etapas que envolvem um projeto sem sustenta-
bilidade. É importante dizermos que, com esse exemplo, não queremos julgar
o trabalho de nenhum desenvolvedor. Ou seja, mesmo que o sistema não seja
sustentável, não podemos afirmar que a pessoa desenvolvedora fez necessari-
amente uma programação ruim. Assim, reforçamos que é muito comum uma
aplicação não se sustentar ao longo do tempo, ainda que a pessoa desenvolvedora
escreva bem. Por outro lado, isso pode significar que ela tomou más decisões
de arquitetura. Então, mesmo que ela escreva bem, por dentro o desenho pode
estar mal feito. E conforme o tempo passa é necessário usar uma “borracha”
na aplicação, fazendo com que existam várias marcações que geram diversos
problemas na estrutura do sistema. Visualizar essas fases pode nos ajudar a
compreender como tudo isso acontece na prática. O objetivo é refletirmos
sobre nossas decisões, para que possamos desenvolver aplicações totalmente
sustentáveis.
Fase 1
Na primeira fase do desenvolvimento de uma aplicação, escolhemos o banco de

dados, criamos os cadastros, validações e selecionamos um servidor web. Depois
disso, é necessário criar Controllers e Views para mostrar as formas de apresentar
os dados. Além disso, é necessário pensar na maneira que faremos a autenticação
e os Upload dos arquivos.
Ainda nessa fase, geralmente o cliente pede por determinada quantidade de

cadastro, sinaliza o que deve ficar na web e solicita login e senha. Esse é
um processo simples, que qualquer framework básico, de qualquer linguagem,
pode resolver. Afinal de contas, são vários CRUDs com algumas validações e
autenticações.
Fase 2
Na segunda fase, o cliente solicita que façamos algumas mudanças. Normal-

mente, precisamos colocar regras de negócio importantes para atender os pedi-
dos desse cliente. Como essas regras farão parte de momentos do cadastro, certas
ações devem acontecer nesse primeiro acesso dos usuários. Isso irá depender dos
objetivos do negócio. Fora isso, criaremos algumas APIs para deixar disponível
aos parceiros. E consumimos APIs para pegar alguns dados. Depois disso,
precisaremos de autorização, isto é, cada usuário poderá fazer cadastro e login
de uma forma diferente. Em seguida, precisaremos de alguns relatórios. Por fim,
é necessário guardar alguns logs ( informações para verificar possíveis erros).
Fase 3
Nesta fase, o sistema começa a ter mais acessos, por isso precisamos fazer
Upgrade de hardware, ou seja, precisamos realizar uma escala vertical para
melhorar o hardware e segurar a quantidade maior de acessos ao software.
Depois, começaremos a trabalhar com cache, consumindo API de parceiros. Isso
faz com que o sistema fique sujeito a algumas regras externas. Por exemplo, ao
fazermos um checkout da empresa “X” de gateway de pagamento precisamos
estar prontos para que nossa aplicação esteja sujeita às regras dessa API externa.
Além disso, mais relatórios serão necessários para analisarmos os eventos, caso
aconteça algum erro na aplicação.
Fase 4
Na fase quatro, o sistema tem ainda mais acessos e precisa de mais Upgrade de
hardware. Consequentemente, precisamos de mais relatórios e consultas. Além
disso, surgem algumas dificuldades no banco de dados, devido ao aumento
dos acessos nele. Então, é preciso gerar alguns comandos, podendo ser via
linha de comando mesmo, para conseguir fazer alguns relatórios ou para
exportar algumas informações. Durante o processo, alguns problemas podem ter
acontecido, ou até mesmo algumas mudanças na empresa, por isso, é necessário
criar a versão 2 da API, mas a versão 1 precisa ser mantida.
Fase 5
Na fase cinco, precisamos escalar o software horizontalmente. Assim, ao invés

de aumentar o hardware precisamos aumentar a quantidade de máquinas, pois
sabemos que não existe hardware infinito. Ao fazer isso, percebemos alguns
problemas. Por exemplo, vemos a necessidade de trabalharmos com sessão
externa, porque o sistema está rodando em máquinas diferentes.
Por causa dessas mudanças, precisaremos fazer algumas adaptações importantes.

Por exemplo, ter uma sessão no banco de dados e/ou no servidor de cache
para que todos os servidores consigam capturar a mesma sessão. Depois disso,
veremos outro problema. Dessa vez relacionado ao Upload. Antes esses arquivos
ficavam na mesma máquina, mas agora temos várias máquinas e, por isso, é
necessário mudar o sistema de Upload. Podemos usar uma nuvem da Amazon
S3 para conseguirmos baixar esses arquivos. Além disso, os Uploads antigos
devem ser migrados. Conseguimos imaginar como seria trabalhoso fazer tantas
mudanças no banco de dados dessa aplicação. Fora isso, não podemos deixar
nossos arquivos totalmente públicos. Precisamos de uma regra de assinatura
desses arquivos na S3 para que apenas o cliente consiga acessar, quando clicar
uma vez no arquivo, por exemplo. Então, teremos que fazer muita refatoração
somente para conseguir escala horizontal. Geralmente, quando começamos a
desenvolver um software não pensamos nisso, assim, esses problemas começam
a surgir e temos dificuldades em resolver tantas situações complexas.
Continuando com o processo de evolução do sistema, devido à quantidade

crescente de acesso, precisamos fazer autoscaling. Ou seja, fazer com que os
servidores cresçam automaticamente. A situação começa ficar mais complicada,
pois existem muitas mudanças no software. Neste momento, temos que colocar
um pipeline de integração contínua e um deploy contínuo na solução.
Fase 6
Na fase seis do desenvolvimento da aplicação, surge a necessidade de usarmos

GraphQL. Por trabalharmos com uma interface diferente, queremos dar mais
força ao front-end. Então, criamos parte da nossa API utilizando GraphQL.
Lembrando que a API estava trabalhando de um jeito, e quando colocamos
endpoint com GraphQL pode surgir alguns bugs. Pois, afinal de contas mudamos
o formato mantendo a versão 1 e 2 da API. Depois disso, é provável que
tenhamos problemas com os logs. Por exemplo, nossa aplicação estava rodando
e gravando cada log em uma única máquina. Ao trabalharmos com número
maior de máquinas, é dificultoso encontrar o problema pois temos que acessar
todas as máquinas individualmente para verificar os seus logs e identificar
qual delas gerou aquele bug. Por vezes não conseguimos identificar o problema
em nenhuma máquina, então descobrimos que, por fazermos o autoscaling,
a máquina onde o bug surgiu foi a que escalamos e, consequentemente, foi
removida. Assim, perdemos os logs e não conseguimos fazer uma análise do
problema. Vemos a necessidade de ter uma ferramenta onde todos os logs fiquem
guardados no mesmo local, tirando essa dependência de analisar as máquinas

individualmente para procurar em qual delas o bug teve origem.
Depois disso, precisamos integrar o sistema com o novo CRM. Neste momento, já
conseguimos perceber que temos algumas regras de negócio misturadas. Assim,
precisamos mudar nossa SPA (frontend) para React e começar a refatoração.
Fase 7
Na fase sete, percebemos que existem certas inconsistências com os dados do

CRM. Um dos problemas pode estar relacionado à dificuldade de comunicação.
Por exemplo, ao realizarmos um checkout do produto, queremos registrar essa
venda no CRM, mas por algum motivo os dados do sistema não chegam até lá.
Trabalhamos com Rest, e fazemos um HTTP Request no CRM. Então, na hora
que mandamos os dados, simplesmente não são registrados. Nesse caso, alguns
motivos possíveis são: o CRM poderia estar fora do ar naquele momento, o
sistema não enviou os dados corretamente ou tivemos um problema temporário
na rede. Assim, os números do sistema não batem com os dados do CRM.
Sabendo que o mundo está migrando para Docker container kubernetes, vemos
o quanto é bom para nossa aplicação colocá-la para rodar em container. Como
iremos migrar para container precisamos pensar na maneira que faremos o
processo de CI/CD, isto é, a integração contínua e o deploy contínuo. Depois
disso, precisamos de um container registry para trabalhar e fazer os processos.
Além disso, nesta fase, pode acontecer um “pico” de processamento, seguido da

“morte” do sistema. Isso porque, a aplicação usa muita memória e ao executar
uma operação ela “morre”, mas o container não. Normalmente, ele tem uma
memória pequena, por isso rodamos vários e percebemos que alguns containers
começam a “morrer” pois em alguns momentos de fato não foram bem desen-
volvidos. Um loop mal feito ou vai gerar algum arquivo que roda muito tempo e
“mata” o container, ou perderá algumas operações. Assim, precisamos dos logs
dos containers para verificar onde estão os problemas.
Por essas situações, já temos o pensamento de que o sistema está virando um

legado. Devido a quantidade de mudanças nos cadastros, nas autenticações etc.
está sendo cada vez mais difícil mantê-lo no ar. Porém, ainda conseguimos.
Fase 8
Na fase oito, mesmo percebendo que o software está virando um legado, não
queremos refazê-lo. Então, a melhor solução é criar microsserviços em volta
desse sistema. Agora, precisamos fazer a comunicação entre esses microsserviços.
Para isso, a opção mais simples é fazer com que todos acessem o mesmo
banco de dados. Mas com isso começamos a ter alguns problemas de tracing.
Acessamos um microsserviço que se comunicou com outro, depois disso, tivemos
um problema em nossa aplicação e de repente não conseguimos identificar em
qual microsserviço esse problema aconteceu. O que vai dificultar nosso trabalho
nesse sistema. Algumas aplicações começam a ficar mais lentas do que eram
antes de trabalharmos com microsserviços. Isso acontece porque agora teremos

uma dupla latência, isto é, não bate tudo em um único sistema. Caso isso
não esteja bem otimizado, o software fica bem mais lento do que o comum.
Consequentemente, o custo financeiro do sistema ficará elevado. Pois temos
vários containers, vários CI/CD, muito mais espaço sendo guardado, muitos
sistemas de logs e muitos sistemas de cache. Tudo isso, “pesa no bolso da
empresa”.
Fase 9
Na fase nove, não temos mais condições de trabalhar com containers, pois o custo
desses serviços está além do esperado. Assim, vamos para Kubernetes. Se ainda
não soubermos trabalhar com essa tecnologia, é necessário bastante esforço para
aprendermos a maneira adequada de implementá-la em nossa solução.
Depois disso, precisamos mudar novamente o processo de CI/CD. Isso faz

com que os problemas de inconsistência fiquem ainda mais evidentes e o
processo de resiliência do software mais difícil. Temos falhas com o CRM,
pois os microsserviços não estão com resiliência suficientes para funcionar
como esperado. Assim, precisamos separar os bancos de dados e trabalhar com
mensageria (filas). Nesse momento, se não tivermos experiência com filas é
comum perdermos várias mensagens. Por exemplo, se não soubermos trabalhar
com RabbitMQ. Perdemos mensagens e não conseguimos identificar o que
aconteceu com elas. Isto é, o Dead Letter não foi criado e, por isso, temos a
necessidade de contratar consultorias para nos ajudar, elevando ainda mais o

custo para manter a aplicação rodando.
Fase 10 (fase final)
Finalmente chegamos à fase dez. Nesta fase, precisamos usar a nossa imaginação!
O que foi colocado neste tópico não pode ser considerado um exagero perto
do que acontece nos dias de hoje. Percebemos que, conforme essas evoluções
acontecem, o sistema vira um “rabisco de borracha”. O software aparenta ser
um legado, por isso ninguém mais quer “por a mão” nele. Lembrando que os de-
senvolvedores que estão escrevendo esse sistema não são necessariamente ruins.
Provavelmente, eles estão estudando e tentando evoluir, colocando tecnologias
novas. Porém, rastros vão sendo deixados para trás. Isto é, vários backlogs e
débitos técnicos ficam para trás nesse processo de evolução.
Então, se a arquitetura não estiver definida, ou seja, se não pensarmos na susten-

tabilidade do software no dia zero, essas dificuldades continuarão acontecendo
até chegar o momento que não teremos mais alternativas, a não ser refazer todo
sistema. Por isso, é importante arquitetarmos nosso software tendo a clareza do
seu funcionamento para que isso não aconteça quando formos desenvolver.

Livro FullCycle-0.6

Enviado por

Direitos autorais:

Formatos disponíveis

Livro FullCycle-0.6

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Livro FullCycle-0.6

Enviado por

Direitos autorais:

Formatos disponíveis

Full Cycle

Essa versão foi publicada em 2023-01-31

Esse é um livro Leanpub. A Leanpub dá poderes aos autores e editores a partir

© 2021 - 2023 Full Cycle Ltda

Introdução à Arquitetura de Software . . . . . . . . . . . . . . . . . . . . . . . . 7

Sistemas Monolíticos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

Domain Driven Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

Arquitetura Hexagonal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

A importância da Arquitetura de Software . . . . . . . . . . . . . . . . . . 159

Foi em 2015 quando comecei ouvir com frequência o termo microsserviços. A

Grandes empresas e unicórnios precisavam crescer rapidamente, gerar mais

A complexidade de arquitetar, desenvolver, testar, realizar o deploy e monitorar

Com o número de sistemas crescendo exponencialmente, a área de operações

tumados a receber demandas de devs para realizarem quatro deploys diários,

O número de aplicações a serem monitoradas também foi se multiplicando, e

Full Cycle Developers @Netflix

Em 17 de maio de 2018, alguns profissionais da Netflix que já possuíam anos

Imagem retirada do Tech Blog da Netflix.

A Netflix deixou de ser apenas um arquivo “war” e também foi dividida em

Imagem retirada do Tech Blog da Netflix.

Devs com muitas responsabilidades

Se você é uma pessoa desenvolvedora, com certeza já sabe o número imenso

A grande questão é: colocar mais responsabilidades nas “costas” da pessoa

desenvolvedora é realmente a solução?

A solução criada estava na utilização de ferramentas desenvolvidas especifi-

Se você atualmente trabalha em alguma empresa que minimamente possui

de desenvolvimento no dia a dia seja fluido e produtivo, sem tirar o foco na

Você é Full Cycle

Se você participa do fluxo completo de uma aplicação, você é um Full Cycle

Um dos pontos fundamentais que, sem dúvidas, diferencia um desenvolvedor,

Assim, gostaria essencialmente de fazer três “provocações” que ajudarão você

1. Qual a fórmula para criarmos softwares sustentáveis?

Sustentabilidade no dia zero

Geralmente o termo sustentabilidade está relacionado à realização de atividades

De forma geral, desenvolver uma aplicação é extremamente caro e, por isso,

viável no dia a dia e assim se diferenciar de pedidos por ligações telefônicas,

Quando as empresas se dão conta de que determinado software chegou em seu

Sem dúvidas a tecnologia evolui. Novas linguagens, frameworks, bibliotecas são

O software precisa nascer sustentável e continuar em produção pelo maior

Entender sobre arquitetura de software é essencial para desenvolvedores que

É importante dizer que, dentro de uma organização, a arquitetura, de forma

No primeiro tópico, falaremos sobre o arquiteto tecnológico, depois sobre o

arquiteto corporativo, no terceiro tópico sobre o arquiteto de solução e, por

Os profissionais que trabalham nessas modalidades são de grande relevância

Essa pessoa é basicamente alguém com especialidade em uma determinada tec-

Primeiramente, é importante destacar que existem diversos tipos de arquitetos

é necessário que se tenha profissionais com conhecimentos específicos nesses

A Elastic Stack pode ser considerada um bom exemplo da necessidade de ter

Outro exemplo que podemos citar é do arquiteto tecnológico Java. Profissional

Além desses exemplos, podemos encontrar, ainda, arquitetos focados em bancos

A Salesforce e a SAP também possuem tecnologias extremamente específicas,

Apesar de sua importância, pouco se ouve falar em arquitetura corporativa, e,

Quando pensamos em arquitetura corporativa, precisamos ter em mente que

uma software house ou um grande banco. Nesse contexto, temos milhares de

Outro exemplo é de empresas como a Salesforce, que oferece soluções em CRM

A pessoa arquiteta corporativa é essencial dentro de uma companhia, pois

Ela ajudará a alinhar e padronizar, estrategicamente, as áreas dentro da cor-

Neste tópico, nos dedicaremos a entender o que é uma pessoa arquiteta de

Um de seus papéis diários é fazer desenhos arquitetônicos da solução para