O documento discute princípios de arquitetura flexível e escalável, incluindo stateless, cache, proxy reverso e CQRS. Também aborda boas práticas como refatoração, testes e TDD. Finalmente, apresenta padrões como DDD, MDD e camada anti-corrupção.

1. ArquiteturaFlexíveleEscalávelby Cesar Grillo
Dojododia:18/02/2016
EquipedeDesenvolvimentodeSistemas

2. Começandocom 5segredosparaseobterumsistema altamente escalável

3. STATELESS(protocolosemestado)
● protocolodecomunicação,ondeomesmoconsistedeparesderequisiçãoerespostas
independentes.Ex:“IP”e“HTTP”.
● Motivo: Casovocêprecise rodarsuaaplicaçãoemumcluster,vocênãoprendeoclienteemum
“nó”docluster.

4. RequestResponseTime
● otempoqueaaplicaçãolevaparaatenderacadarequisiçãotemqueseromaisbaixopossível
● Solução:otimizarotrabalhoomelhorpossível

5. Cache
● Páginasquenecessitamguardarbancodedadosparaseremrenderizadas
● guardaruma“cópia”dapáginaéimportante
● depoisésómostraraquelacópiaparaopróximoqueacessarapágina

6. RemoteData
● Obancodedadosnãodeveficarnamesmamáquinaqueoservidordeaplicação,ouoendereçodo
bancodeveráserconfigurável
● emumcluster,oidealéquetodososnósacessemomesmobancodedados,ounomínimoque
todososbancosdoclusterestejamsincronizados

7. ProxyReverso
● utilizadoparamascararalgumasdastécnicasdecaching
● paraimplementaralgumastécnicasdecachingeprincipalmenteparaesconderdousuárioque
vocêtemdiversosservidores
● elevaisero“front-end”dasuaaplicação
● Podetambémesconderdousuárioofatodevocêusarum“servidorderecursosestáticos”
● oproxyreversopodemascararoendereçorealdaaplicação

8. “Boaspráticasdeprogramação”

9. Algunsprincípiosqueumbomprogramadordeveseguir:
(V)Refatoraromáximopossível
(V)Semprerealizartestesfuncionaiseunitários
(V)Deixarocódigolimpo(simples,direto,eficiente,elegante…)
(V)Questionarosanalistasdesistemaquandosurgiremdúvidasousugestõesperanteuma
determinadaatividade
(V)Procurarentenderocódigo(nãoresolvercomum“CTRL+C”e“CTRL+V”)
(V)Indentaçãocorreta

10. (V)Nãoexagerarnoscomentários
(V)Manterumpadrãonoscódigos
(V)Evitarcódigo“in-line”muitoextenso
(V)Pareamentocom outrosprogramadores(assimvocêcompartilhaconhecimentoetroca
experiências)
(V)Fazerdiáriasparasabercomofoioexpedienteatéaquelemomento

11. TDD(testdrivendevelopment)

12. BenefíciosdoTDD
(V)Deixaocódigocomqualidade
(V)Ajudaamelhoraroraciocínio doprogramador
(V)Fazoprogramadorsesentirsegurodoqueestáfazendo
(V)Trabalhoemequipe
(V)Documentação(Com ostestesunitários a“documentação” égeradaantesmesmodanovafeatureserimplementadaepermanecefiela
qualquer alteração)

13. DesvantagensdequemnãoutilizaTDD
(X)Dificuldadesemcomeçarafazertestes(faltadeexperiência)
(X)Curvadeaprendizado(dependedavontadeedisponibilidadedoprogramador)
(X)Cultura(programadoresreclamamda“faltadetempo”)

14. Exemplosdetesteunitárioefuncional
testefeitonoNetBeansIDE8.1
testefeitonoseleniumIDE

15. Oprogramadortambémdeveseguirestes3passos:
Vermelho-Verde-Refatora
EscreveumTestequeinicialmente não
passa
Fazotestepassar
Melhora ocódigo

16. DDD(domaindrivendesign)-projetoorientadoadomínio
● nomeoriginadodolivroescritoporEricEvans,donodadomainLanguage(empresade
desenvolvimentodesoftware)
● DDDpodeservistocomoavoltadaorientaçãoaobjetos
● algunspontosimportantesdoDDD: alinhamentodocódigocomonegócio,favorece
reutilização,mínimodeacoplamentoeindependênciadatecnologia

17. MDD(modeldrivendesign)-Projetodirigidopelomodelo
● Utilizandoumalinguagemubíquaépossívelcriarummodelodedomínio,atravésdomdd
● aideiaéqueomodeloabstratodeveserumarepresentaçãoperfeitadoseudomínio
● tudoqueaparecernonegócio,deveestarnomodelo
● Agrandemaioriadaspessoasquemodelamodomíniosãonecessariamentepessoasquecolocama
mãoemcódigo(Hands-onModelers)
● mddéumprocessocontínuo

18. BlocosdeconstruçãodoMDD
Interface do usuário - responsável pela exibição de
informações do sistema ao usuário e também por interpretar
comandos dousuário
Aplicação - apenas uma camada fina, responsável por
conectar aInterfacedeUsuárioàscamadasinferiores
Domínio - representa os conceitos, regras e lógicas de
negócio. Todoofoco deDDDestánessacamada
Infra-estrutura - fornece recursos técnicos que darão
suporte àscamadassuperiores

19. Camadaanti-corrupção
● Quandosetemumsistemalegado,comcódigomuitocomplexoeestasendoescritoumsistemanovo
comocódigorazoavelmentebemfeito,devesecriarumacamadaentreessesdoissistemas
● responsávelportraduzireadaptaraschamadasparaosistemalegado,usandoumafachada
interna

20. CQRS(Responsabilidade deSegregaçãodocomandoQuery)
● padrãodearquiteturadocumentadoporGregYoung
● essepadrãoseparaasoperaçõesdeleituraeescritaemdiferentesmodelos
● OCQRSfoidocumentadoduranteaimplementaçãodeprojetosutilizando
osconceitosdeDDD(domaindrivendesign)
● OCQRSéumabordagem,umaformadepensare nãoumareceitapronta
● Eleéaplicávelagrandessistemasdistribuídos,permitindoassim
construiraplicaçõesmaisescaláveis

21. Exemplode padrãoCQRS
UI - dependendo do usuário, pode
executar opções de leitura ou escrita
dedados
Service Interfaces - pode interagir
commodelosdiferentes
Querymodel-operaçõesdeleitura
Commandmodel-comandos

22. Porúltimoenãomenosimportante…
BRAINSTORMING

23. Referências
● http://www.infoq.com/br/news/2011/10/construindo-sistema-escalavel
● http://sobrecodigo.com/os-4-segredos-para-um-sistema-altamente-escalavel/
● http://eltonminetto.net/docs/app_web_escalaveis.pdf
● http://www.profissionaisti.com.br/2014/10/quais-design-patterns-devo-usar-no-meu-projeto/
● http://www.infoq.com/br/news/2011/11/cqrs