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!
Arquitetura limpa no Front-End
By João Vinicius de Paula
