O documento discute arquitetura web e desenvolvimento para a web. Ele apresenta três evoluções na abordagem de desenvolvimento, começando por separar a lógica da apresentação, depois introduzindo o padrão MVC, e finalmente focando no Domain-Driven Design. O documento também discute tecnologias como Java EE, EJB, JPA e JSF que podem ser usadas para implementar uma arquitetura web robusta.

1. Arquitetura Web
Ralph J. R. Filho

2. Cenário – Desenvolvimento Web
Qual a melhor forma
de desenvolver
para a Web?

3. Cenário – Simplicidade
Escrever lógica de negócio em uma página de
script
JSP
ASP
PHP

4. Exemplo
include_once ("check.php");
if ($check['level'] > 4)
{
print "<font face='Arial' size='5' color='#FF0000'>";
print "<b>Illegal Access</b>";
print "</font><br>";
print "<font face='Verdana' size='2' color='#000000'>";
print "<b>You do not have permission to view this page.</b></font>";
exit; // Stop script execution
}

5. Importante esclarecer que
Se a abordagem escolhida para a arquitetura for
precária, a escolha da tecnologia influencia pouco.

6. Importante esclarecer que
Existem “n” opções no mercado para desenvolvimento
de software

7. Importante esclarecer que
O que faz diferença e agrega valor é uma arquitetura
bem definida

8. Importante esclarecer que
A partir da arquitetura, seleciona-se as tecnologias
adequadas à natureza dos projetos
Exemplo: casa
Para que público é a casa?
Qual o clima do local?
Quais as características do terreno?
Qual o custo/benefício das madeiras na região?

9. Exemplo: software
Para que público é o software? (b2b, b2c, ...)
Qual o tipo do software (negócio, ferramenta,
embarcado)
Quais os requisitos funcionais?
Quais os requisitos não-funcionais?
Vai rodar em que ambiente?
É cliente-servidor ou cliente?
...

10. Ou seja
Uma arquitetura e conjunto de tecnologias
montados para um projeto “A” pode não ser a
mais adequada para um projeto “B”
Cada caso é um caso

11. Analogia
Usa-se o mesmo tipo de material para estas
duas construções?

12. Software

13. Cenário
Com a falta de padrões arquiteturais pode
ocorrer
Dificuldade de manutenção
Baixa escalabilidade
Baixo nível de reuso
Código “espaguete”

14. Dê manutenção nisso

15. Cenário – Spaghetti code
10 i = 0
20 i = i + 1
30 PRINT i; " squared = "; i * i
40 IF i >= 10 THEN GOTO 60
50 GOTO 20
60 PRINT "Program Completed."
70 END

16. Technical Debt (Débito técnico)
“The obligation that a software
organization incurs when it
chooses a design or
construction approach that's
expedient in the short term
but that increases
complexity and is more
costly in the long term”

17. O investimento em arquitetura é necessário,
porém, seus benefícios são difíceis de
mensurar
De forma simples, pode-se comparar obtendo
resultados de projetos (sucesso/insucesso),
análises de produtividade (hora/homem) e
índices de qualidade (bugs por
funcionalidade, medida de desempenho, etc.)

18. Evolução (1)

19. Evolução (1)
Separar a lógica da apresentação
ASP.Net
PHP + Smarty
JSF

20. Melhora a situação, mas...
Geralmente sobrecarrega o código aonde está
a lógica
Causando os mesmos problemas

21. Anti-patterns

23. Evolução (2)

24. Evolução (2)
Separar a lógica da apresentação, usando um
meio-de-campo

25. Filosofia MVC
Modelo
Controle
Visão

26. MVC
A visão não precisa saber que o modelo existe
e vice-versa

27. MVC
Visão
Cadastra-Clientes.html
Controle
ClientesControl.java
Modelo
ClientesModel.java

28. MVC
Já é alguma coisa, mas pode melhorar
O código no modelo tende à ficar extenso
MVC é uma filosofia de arquitetura, pode ser
adaptada
Abre aspas
Alguns modelos e métodos servem como guias.
Não são “doutrinas”.
Não é pecado personalizar

29. Evolução (3)

30. Evolução (3)
O esforço de programação deve estar na
modelagem do domínio de negócio, afinal... é
disso que se trata a programação de sistemas
de negócio
Isto se aplica a softwares de negócio
Outros tipos de software: ferramentas,
embarcado

31. Domain-Driven Design
Conjunto de princípios
Baseado no MVC
Foco no reuso de código
Facilidade de implementação
Equipes distribuídas
Arquitetura orientada a serviço
Cloud-computing / Web-Services

32. DDD

33. A camada de Domínio
Contém toda a lógica do negócio
Assinatura de métodos
Baixo nível de acoplamento
Aumenta o número de arquivos, reduz o
número de linhas de código
Modelo de arquitetura que evoluiu com a
tecnologia

34. Montando uma arquitetura
Tecnologia utilizada
Java EE

35. Java EE
Conjunto de especificações
Dita como deve ser implementado
Transfere complexidade repetitiva das
aplicações de negócio para a arquitetura
Java EE 6

36. ?
INFRA EJB JPA
DOMAIN Repos. Service Entity
CONTROL JSF
?

37. Oracle Glassfish Community
Implementa o Java EE
Gerencia transações e conexões com o BD
Disponibiliza ambiente para servlets
Controla aspectos de segurança e acesso
Concorrentes
JBoss AS
Apache Geronimo

38. Enterprise Java Beans (EJB)
Especificação versão 3.1 (10/12/2009)
Integra-se com a camada de persistência
Controla estado de beans
Controla aspectos de segurança
Recursos de agendamento
Suporte à web services

39. Java Persistence API (JPA)
Especificação 2.0 (10/12/2009)
Oferece estrutura para mapear entidades do
banco de dados
Controla aspectos de CRUD
Oferece os benefícios de O.O. para BD
relacionais
Implementadores: Hibernate, TopLink, etc.

40. Java Server Faces (JSF)
Especificação 2.1 (22/10/2010) (Mojarra)
Disponibiliza uma separação clara entre a
camada de visão e a camada de controle
Disponibliza templates
Disponibiliza componentes visuais
Disponibiliza AJAX e controle de eventos

41. PrimeFaces
Biblioteca de componentes visuais que utiliza o
JSF e o Jquery (centenas de componentes)
Atualmente na versão 3.2
Simplifica a construção de páginas web
Ajuda o programador a manter o foco na lógica
do negócio
Concorrentes
RichFaces
IceFaces

42. Exemplo
Lista de Notas Fiscais
lista-nota-fiscal.xhtml
NotaFiscalMB.java
NotaFiscalRepository.java
NotaFiscalRepositoryJPA.java
NotaFiscalService.java
NotaFiscalServiceImpl.java
NotaFiscal.java

43. Exemplo
<p:dataTable var="nf" value="#{notaFiscalMB.notasFiscais}" sortBy="#{nf.numero}" id="nf_table" >
<f:facet name="header">Lista de Notas Fiscais</f:facet>
<p:column id="modelColumn" filterBy="#{nf.numero}" headerText="Número" sortBy="#{nf.numero}">
<h:outputText value="#{nf.numero}" /></p:column>
<p:column id="yearHeader" headerText="Série" sortBy="#{nf.serie}">#{nf.serie}</p:column>
<p:column id="manufacturerHeader" headerText="Emitente" sortBy="#{nf.razaoSocialDestinatario}">
#{nf.razaoSocialDestinatario}</p:column>
<p:column id="colorHeader" headerText="Data Emissão" sortBy="#{nf.dataEmissao}">
#{nf.dataEmissao}</p:column>
<p:column id="vlNota" headerText="Valor Nota Fiscal" sortBy="#{nf.valor}">
#{nf.valor}</p:column>
</p:dataTable>

44. Exemplo

45. Resultado

46. Exemplo

47. Exemplo

48. Notem
Os nomes no singular
Os nomes em inglês
O tamanho dos nomes dos arquivos
A limpeza e a clareza dos códigos-fonte (POJO's)

49. Posso substituir a camada de Infra, Controle,
Visão, Servidor de Aplicação, Banco de
Dados e a saída para o usuário
No entanto, a modelagem de domínio pode
continuar intacta

50. O domínio representa o entendimento do
programador sobre a lógica do negócio

51. É no domínio que ficará a inteligência do
negócio
Regras de Negócio
Eu digo o quê deve ser feito e não como
Padrões ISO são assim
Modelos de desenvolvimento são assim
O como é feito vai nas camadas periféricas da
arquitetura que implementam o domínio

52. Tenho condições de fazer

53. Caminho de implementação
Arquitetar
Assinar métodos do domínio
Mapear entidades
Implementar
Implementar repositórios e regras de negócio
Implementar interfaces e controladores
Implementar validações e tratamento de erros
Implementar testes unitários

54. Adição de boas práticas
Inspeção de código
Projeto de solução (UML)
Foco no negócio
Programação coletiva (o código pertence à
organização e não ao programador)
Padrões devem ser evoluídos constantemente

55. Nota
Não há nirvana para uma organização. O apse
é a melhoria contínua de processos bem
definidos, estáveis e adequadamente
quantificados

56. Vantagens e Desvantagens
Estabilidade Back-end não é trivial!
Comunidades ativas Curva de aprendizado
Material didático Debug em alto nível
Manutenibilidade
Produtividade
Desempenho
Rápido de Prototipar

57. Tempo investido
Aumenta o investimento em pensar como fazer
para diminuir o investimento em fazer
Mais planejamento, menos esforço

58. Tempo Investido
E quanto à liberações urgentes?
Refactoring
Planejamento de releases é crucial
Organização da equipe e da demanda é crucial
Política de gerenciamento de configuração
Política de manutenção

59. Lembrando
Cada caso é um caso (natureza dos projetos)
Todas as abordagens tem vantagens e
desvantagens
A melhor solução é aquela que atende à tua
necessidade
É bom manter os olhos abertos às novidades
A inovação pode ser um diferencial competitivo

60. Ambiente decente

61. Ambiente Decente
Para desenvolvimento, em
geral, os S.O.'s pinguim-like
são superiores
Escolher uma IDE é como
escolher um time de futebol.
Mas o eclipse tem uma
legião de fãs.

62. JAVA em 2012
#1 Linguagem de programação
9 milhões de desenvolvedores
1 bilhão de downloads por ano
3 bilhões de devices rodando java
97% de computadores empresariais
17 anos de mercado

63. Java - JCP

64. Para encerrar – Martin Fowler
“Any fool can write code that a computer can understand. A good
programmer write code that humans can understand”