porque discutir sobre como eu faço meus pacotes?

primeiro ponto de entrada no projeto!

ajuda na manutenabilidade do código

visualização das funcionalidades

ESTRUTURA padrão De PROJETO

COMO VOCÊ ESTRUTURA SEU PROJETO?

MODEL

DAO

SERVICE

SE TIVERMOS QUE FAZER UMA MODIFICAÇÃO...

temos que modificar em vários lugares!

BAIXA COESÃO!

projetos crescem...

e se quisermos CRIAR MÓDULOS?

 BAIXA MODULARIDADE

código está totalmente espalhado!

que tipo de divisão é essa?

CÓDIGO AGRUPADO POR CAMADA

=

PACOTE POR CAMADAS

(PACKAGE BY LAYER)

• BAIXA COESÃO
  
• BAIXA MODULARIDADE
  
• CRESCIMENTO VERTICAL DO CÓDIGO
  
• FUNCIONALIDADES ESCONDIDAS
  
• POUCO ABSTRATO
  

COMO RESOLVER ESTES PROBLEMAS?

ERA UMA VEZ UMA EQUIPE DE DESENVOLVEDORES...

todo mundo fazia parte da mesma equipe

poucas pessoas

mais divisão de conhecimento

pessoal de atendimento confuso

REUNIÕES LONGAS

qual solução?

separação...

... MAS POR QUAL CRITÉRIO?

funcionalidades do site!

BUSCA

WEB

PAGAMENTO

 BACK-END

BUSCA

front-end

PAGAMENTO

TIMES MAIS ESPECIALIZADOS

ATENDIMENTO SABE COM QUE EQUIPE FALAR

REUNIÕES FOCADAS

SE TIVERMOS QUE FAZER UMA MODIFICAÇÃO...

está tudo no mesmo lugar!

CÓDIGO AGRUPADO POR funcionalidade

=

PACOTE POR FUNCIONalidade

(PACKAGE BY feature)

• alta coesão
  
• alta modularidade
• crescimento horizontal
• fácil navegação do código
• mais abstrato
• funcionalidades mais claras

como dividir então nosso código?

Começamos já criando pacotes? (Top-Down)

Criamos as classes e juntamos em pacotes? (Bottom-Up)

MELHORES PRÁTICAS PRA DIVIDIR POR FUNCIONALIDADE

PrincÍpio do reuso

depender de um pacote significa depender de todo pacote

classes usadas em conjunto devem permanecer no mesmo pacote

Princípio do encerramento (closure)

todas modificações de uma feature devem ser feitas em somente um lugar

DEPENDÊNCIAS DEVEM FORMAR UM GRAFO DIRECIONADO ACÍCLICO

DEPENDÊNCIAS CÍCLICAS CRIAM conflitos para modificações

grafo direcionado acíclico

que acontece se modificarem o pacote 'task'?

criando um ciclo

COMO QUEBRAR O CICLO?

INJEÇão DE DEPENDÊNCIA

CRIANDO NOVO PACOTE COM DEPENDÊNCIAS DOS DOIS!

ENTÃO...

DESIGN FICA TOP-DOWN (COMEÇANDO POR PACOTES)

OU BOTTOM-UP (COMEÇANDO PELAS CLASSES)?

nÃO HÁ COMO ARQUITETURAR PACOTES DE MANEIRA TOP-DOWN!

VOCÊ PRECISA ENTENDER COMO AS CLASSES VÃO SE DISTRIBUIR

pacotes em constante fluxo!

PACOTES REPRESENTAM NA VERDADE COMO NOSSA APLICAÇÃO DEVE SER CONSTRUÍDA

MEDIDA QUE SISTEMA CRESCE

• AGRUPAREMOS AS CLASses reusadas em conjunto (reuse/abstração)
• agruparemos em projetos menores para diminuir quantidade de releases (closure)

QUIZ

por que frameworks como spring usam pacote por camada?

SUAS FUNCIONALIDADES SÃO AS CAMADAS!

PRIMEIRO TECH TALK DE BOAS PRÁTICAS!

MUITOS MAIS POR VIR!

ALGUM ASSUNTO PREFERENCIAL?

PERGUNTAS?