Arquitetura limpa no Front-end

Arquitetura limpa no Front-end

João Vinicius
Front-end na

Imagine que você seja um pedreiro e seu cliente peça para fazer uma churrasqueira

- Planta

- Validação e acompanhamento do arquiteto

O arquiteto

- Organização e estilo

- Levantamento de requisitos

- Segue as características definidas pela planta

- Transforma a abstração da planta na construção concreta.

O pedreiro

A arquitetura do software deve conter o levantamento de requisitos através de diagramas, fluxogramas de processo, modelos ou listas documentadas de tarefas que o software deve executar.

Os componentes utilizados devem ser representados através de conceitos abstratos apresentando suas relações e regras que devem ser levados em consideração na hora de implementar na forma de código.

(

Dar nomes é como assentar tijolos

Ser preciso: precisamos passar a ideia central da nossa variável, método ou função, sem dar voltas, sendo conciso e direto.

- Eventos

- Nome de componente

- Nome de arquivos

- Dados reativos

- Dados computados

- Métodos

Não ter medo de nomes grandes: um nome bem descritivo, mesmo que seja grande, irá possibilitar uma melhor compreensão e posterior manutenção do código.

- resources/api/v1/authentication/action/ResendUserPasswordRecoveryEmail.ts

)

  • S  rp - Principio da Responsabilidade Única
  • O cp - Princípio Aberto-Fechado
  • L  sp - Princípio da Substituição de Liskov
  • I   sp - Princípio da Segregação da Interface
  • D  ip - Princípio da inversão da dependência

Principio da
Responsabilidade

Única

SRP

ButtonDefault.vue

AccountFactory.ts

OCP

Princípio
Aberto
Fechado

para extensão

para modificação

InputDefault.vue

EmailDefault.vue

LSP Princípio da Substituição de Liskov

A teoria diz : “Dado um Tipo T, todos os seus subtipos S podem ser usados como seus substitutos sem que haja impactos no sistema.”

 I
 S
 P

Princípio da

Segregação da

Interface

DataMapper.ts

AccountDM.ts

DIP Princípio da inversão da dependência

"Os sistemas mais flexíveis são aqueles em que as dependências de código-fonte se referem apenas abstrações, não a itens concretos"

Como seria a "planta" de arquitetura de um software?

  • Componentes
  • Responsabilidades
  • Relacionamentos

D
A
D
O
S

"O termo objeto é diferente do termo entidade.
A entidade preocupa-se apenas com os dados enquanto o objeto preocupa-se tanto com os dados como com os métodos com os quais os dados são manipulados."

Ex: Carro e CNH

  • Componentes
  • Responsabilidades
  • Relacionamentos

Layout

Apenas comportamento e apresentação

Componentes sem comunicação direta com outra camada (ex: api)

INTERFACE

  • Componentes
  • Responsabilidades
  • Relacionamentos

Então quem faz a comunicação com os serviços?

Padrão de gerenciamento de estado

  • O estado, a fonte da verdade da nossa aplicação
  • A visão, um mapeamento declarativo do estado
  • As ações, as maneiras possíveis pelas quais o estado pode mudar em reação às entradas do usuário na visualização
  • Componentes
  • Responsabilidades
  • Relacionamentos
  • Componentes
  • Responsabilidades
  • Relacionamentos

Benefícios

  • Fácil compreenção, manutenção, refatoração ou migração
  • Fácil implementação de novas funcionalidades
  • Padrão bem definido
  • Componentesde interface "burros"
  • Independência de framework/biblioteca
  • Reaproveitamento de código
  • Código testável
  • Escalabilidade vertical e horizontal
  • DRY
  • ...

Dúvidas?

ESTAMOS
CONTRATANDO!

Made with Slides.com