| ... | @@ -3,7 +3,9 @@ |
... | @@ -3,7 +3,9 @@ |
|
|
|
|
|
|
|
# Arquitetura do Sistema
|
|
# Arquitetura do Sistema
|
|
|
|
|
|
|
|
Esta é a página onde irá ficar todas as informações da Arquitetura do seu projeto.
|
|
A visão geral e simplificada do projeto pode ser representada pelo diagrama abaixo.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Front-End
|
|
## Front-End
|
|
|
|
|
|
| ... | @@ -28,3 +30,36 @@ A arquitetura selecionada para o front-end mobile é o MVCR (Model-View-Controll |
... | @@ -28,3 +30,36 @@ A arquitetura selecionada para o front-end mobile é o MVCR (Model-View-Controll |
|
|
Essa arquitetura se assemelha bastante com a MVC utilizada na versão web, com a diferença que agora a View não faz mais o trabalho de exibir as telas. Essa ocupação fica em outra camada (Router).
|
|
Essa arquitetura se assemelha bastante com a MVC utilizada na versão web, com a diferença que agora a View não faz mais o trabalho de exibir as telas. Essa ocupação fica em outra camada (Router).
|
|
|
|
|
|
|
|
Como pode se ver na imagem, o fluxo de informações começa na View, onde todas as informações são exibidas e todas interações do usuário são recebidas. A Router, então, se responsabiliza de como exibir novas telas, se necessário. A controller é encarregada de verificar os dados recebidos, e, finalmente, na Model, é onde se recebe pedidos da controller para mandar ou receber dados do banco de dados.
|
|
Como pode se ver na imagem, o fluxo de informações começa na View, onde todas as informações são exibidas e todas interações do usuário são recebidas. A Router, então, se responsabiliza de como exibir novas telas, se necessário. A controller é encarregada de verificar os dados recebidos, e, finalmente, na Model, é onde se recebe pedidos da controller para mandar ou receber dados do banco de dados.
|
|
|
|
|
|
|
|
## Backend
|
|
|
|
|
|
|
|
A camada de backend da aplicação trabalha sobre o padrão de microsserviços, que permite maior escalabilidade e isolamento. Assim, identificar os pontos de falha da aplicação se torna uma tarefa menos onerosa.
|
|
|
|
|
|
|
|
### Modelagem via DDD
|
|
|
|
|
|
|
|
Essa arquitetura é explicada através de uma modelagem chamada DDD (*Domain Driver Design*), que permite com que se entenda quais os obetivos do *business* empregado na aplicação, auxiliando o desenvolvimento indicando quais necessidades o mesmo deve suprir. Abaixo está uma aplicação simples dessa modelagem na interpretação dos alunos. Os *bounded contexts* são traduzidos como microsserviços para o projeto.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Pode-se perceber que existe uma relação de *downstream* por parte do contexto de voluntários e instituições, e uma relação de *upstream* de oportunidades para os demais contextos. Isso significa que o contexto de oportunidade é de suma importância para o negócio pelo qual o software deve satisfazer. Ainda pode-se reparar que esta modelagem permite com que se entenda quais as entidades cada contexto é responsável.
|
|
|
|
|
|
|
|
Para entender melhor as nomenclaturas do software, esta metodologia também prega pela criação de uma linguagem universal, que deve ser entendida por todos envolvidos no projeto. Esta linguagem facilita o entendimento da aplicação e dos contextos que a envolvem. Assim, criamos um glossário, descrito abaixo.
|
|
|
|
|
|
|
|
- **USUÁRIO**: Pessoa que acessa o aplicativo com a finalidade de usá-lo.
|
|
|
|
- **CLIENTE**: Parte da aplicação que proporciona a visualização gráfica e a interação da mesma para o usuário.
|
|
|
|
- **SERVIDOR**: Parte da aplicação que responde às necessidades do cliente.
|
|
|
|
- **VOLUNTÁRIO**: Usuário que acessa a aplicação com a finalidade de encontrar oportunidades.
|
|
|
|
- **OPORTUNIDADE**: Trabalho voluntário disponibilizado por uma instituição.
|
|
|
|
- **INSTITUIÇÃO**: Usuário que provê oportunidades para voluntários.
|
|
|
|
- **DESCRIÇÃO**: Informações sobre uma determinada entidade do sistema.
|
|
|
|
- **LISTAGEM**: Lista de oportunidades disponíveis.
|
|
|
|
- **INTERESSE**: Intenção do voluntário em aplicar-se ao trabalho voluntariado especificado em uma oportunidade.
|
|
|
|
- **PERFIL**: Parte da aplicação reponsável por manter informações do usuário, podendo este ser representado por um voluntário ou por uma instituição.
|
|
|
|
- **CADASTRO**: Parte da aplicação responsável pela criação de um perfil.
|
|
|
|
- **LOGIN**: Parte da aplicação responsável pela permissão de acesso a um perfil já cadastrado de um usuário.
|
|
|
|
|
|
|
|
### Arquitetura dos microsserviços
|
|
|
|
|
|
|
|
O padrão arquitetural *Layers* (Camadas) foi adotado por cada microsserviço constituinte da camada de backend. Sabendo disso, as camadas presentes para este padrão vão de encontro com os conceitos de DDD, portanto têm-se de forma isolada a infraestrutura (**infraestructure**), os repositórios (**repositories**), os serviços (**services**) e as interfaces da aplicação (**APIs**). Assim, as responsabilidades de cada camada atua de maneira isolada, onde cada a cadeia de dependências se dá através de interfaces bem definidas. O dado que trafega pelas camadas é chamado de entidade, e pode ser identificado como voluntário, oportunidade ou instituição, sendo esta entidade definida de acordo com o microsserviço que a mesma se encontra. Abaixo está uma ilustração genérica que pode representar qualquer um dos três microsserviços.
|
|
|
|
|
|
|
|
 |
