|
|
|
| [Home](home) | [Escopo e Cronograma](escopo) | [Processo](processo) | [Design/Mockups](design_mockups) | [Configuração](configuracao) | [**Arquitetura**](arquitetura) | [Código](codigo) | [BD](banco_dados) | [Qualidade](qualidade) | [Utilização](utilizacao) |
|
|
|
|
| :----------: | :---------------------------: | :------------------: | :--------------: | :--------------------------: | :----------------------------: | :--------------: | :---------------: | :--------------------: | :----------------------: |
|
|
|
|
| [Home](home) | [Gerência](gerencia) | [Processo](processo) | [Design/Mockups](design_mockups) | [Configuração](configuracao) | [_Arquitetura_](arquitetura) | [Código](codigo) | [Banco de Dados](banco_dados) | [Utilização](utilizacao) |
|
|
|
|
| :----------: | :------------------: | :------------------: | :------------------------------: | :--------------------------: | :--------------------------: | :--------------: | :---------------------------: | :----------------------: |
|
|
|
|
|
|
|
|
# Arquitetura do Sistema
|
|
|
|
|
| ... | ... | @@ -44,25 +44,23 @@ TBD |
|
|
|
|
|
|
|
### Definições de linguagem e bibliotecas
|
|
|
|
|
|
|
|
* Linguagem: TypeScript
|
|
|
|
* Frameworks: Express e Node.
|
|
|
|
- Linguagem: TypeScript
|
|
|
|
- Frameworks: Express e Node.
|
|
|
|
|
|
|
|
Na sprint 0 foi feito um questionário com o time para quantificar o conhecimento dos alunos em linguagem, frameworks e bancos de dados para determinar quais as tecnologias que seriam usadas de acordo com o conhecimento geral do time.
|
|
|
|
|
|
|
|
Com base no questionário e em discussões com o time, foi definido utilizar a linguagem TypeScript para o desenvolvimento backend juntamente com o Node.js e o Express, essa stack de tecnologia foi definida porque o framework Express é um dos mais utilizados em conjunto do Node.js e ele conta com varias funcionalidades que facilitam o desenvolvimento da aplicação.
|
|
|
|
|
|
|
|
### Módulos do Sistema:
|
|
|
|
|
|
|
|
* **Routes**: Arquivos possuem o nome do serviço que será disponibilizado. Nele ficam registrados os endpointes da aplicação, ou seja, os caminhos após o endereço do servidor como `/user/specialist` e qual o tipo de chamada o endereço irá receber `GET`, `POST`, `PUT` ou `DELETE`
|
|
|
|
* **Services**: Nesta pasta ficam os arquivos que validam nossas regras de negócio, utilizando o **repository** para fornecer os dados do banco e realizar as validações.
|
|
|
|
* **Repository**: Todos os arquivos aqui fazem as chamadas ao banco de dados através das **models** passando os parâmetros adequados para as funções desejadas.
|
|
|
|
* **Models**: Nesta pasta estão todas as representações das tabelas do nosso banco de dados, mas de uma forma com que possamos trabalhar facilmente no código: classes. Os dados são recuperados do banco e convertidos para as classes criadas.
|
|
|
|
|
|
|
|
### Módulos do Sistema
|
|
|
|
|
|
|
|
- **Routes**: Arquivos possuem o nome do serviço que será disponibilizado. Nele ficam registrados os endpointes da aplicação, ou seja, os caminhos após o endereço do servidor como `/user/specialist` e qual o tipo de chamada o endereço irá receber `GET`, `POST`, `PUT` ou `DELETE`
|
|
|
|
- **Services**: Nesta pasta ficam os arquivos que validam nossas regras de negócio, utilizando o **repository** para fornecer os dados do banco e realizar as validações.
|
|
|
|
- **Repository**: Todos os arquivos aqui fazem as chamadas ao banco de dados através das **models** passando os parâmetros adequados para as funções desejadas.
|
|
|
|
- **Models**: Nesta pasta estão todas as representações das tabelas do nosso banco de dados, mas de uma forma com que possamos trabalhar facilmente no código: classes. Os dados são recuperados do banco e convertidos para as classes criadas.
|
|
|
|
|
|
|
|
### Diagrama de Fluxo
|
|
|
|
|
|
|
|
As camadas da aplicação se comunicam da seguinte maneira, um fluxo de dados inicia com a requisição do usuário na camada **Route**, que valida os dados e encaminha para a **Service** onde são chamados os métodos do **Repository**, nele ocorre as ações com o banco como `SELECT`, `INSERT`, `UPDATE` e `DELETE`. O **Repository** utiliza a **Model** que representa as nossas tabelas do banco.
|
|
|
|
As camadas da aplicação se comunicam da seguinte maneira, um fluxo de dados inicia com a requisição do usuário na camada **Route**, que valida os dados e encaminha para a **Service** onde são chamados os métodos do **Repository**, nele ocorre as ações com o banco como `SELECT`, `INSERT`, `UPDATE` e `DELETE`. O **Repository** utiliza a **Model** que representa as nossas tabelas do banco.
|
|
|
|
|
|
|
|
Seguindo um fluxo que percorre a estrutura: **Route > Service > Repository > Model.**
|
|
|
|
|
| ... | ... | @@ -82,11 +80,11 @@ O sistema foi dividido em `camadas` e podemos ver as principais abaixo: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- **Components (``átomo``)**: Na química, os átomos são os blocos de construção básicos da matéria. Assim, os átomos das nossas interfaces servem como os blocos de construção fundamentais que compõem todas as nossas interfaces de usuário. Esses átomos incluem elementos básicos como labels, inputs, botões etc., sendo a parte mais genérica e reutilizável da interface do usuário. Não contém regra de negócio.
|
|
|
|
- **Components (`átomo`)**: Na química, os átomos são os blocos de construção básicos da matéria. Assim, os átomos das nossas interfaces servem como os blocos de construção fundamentais que compõem todas as nossas interfaces de usuário. Esses átomos incluem elementos básicos como labels, inputs, botões etc., sendo a parte mais genérica e reutilizável da interface do usuário. Não contém regra de negócio.
|
|
|
|
|
|
|
|
- **Containers (``molécula``)**: Na química, moléculas são grupos de átomos ligados entre si que assumem novas propriedades. Nas interfaces, as moléculas são grupos simples de elementos da interface do usuário funcionando como uma unidade. Por exemplo, um label de formulário, um input de pesquisa e um botão podem se unir para criar uma molécula de formulário de pesquisa. É a parte responsável por agrupar componentes que serão utilizados em uma tela. Contém regra de negócio/lógica.
|
|
|
|
- **Containers (`molécula`)**: Na química, moléculas são grupos de átomos ligados entre si que assumem novas propriedades. Nas interfaces, as moléculas são grupos simples de elementos da interface do usuário funcionando como uma unidade. Por exemplo, um label de formulário, um input de pesquisa e um botão podem se unir para criar uma molécula de formulário de pesquisa. É a parte responsável por agrupar componentes que serão utilizados em uma tela. Contém regra de negócio/lógica.
|
|
|
|
|
|
|
|
- **Screens (``organismo``)**: Organismos são componentes de IU complexos, compostos por grupos de moléculas e/ou átomos e/ou outros organismos. Esses organismos formam seções distintas de uma interface. Responsável pela a apresentação dos containers e interage com a navegação entre as telas. Possui pouca lógica/regra de negócio (menos do que o container). Onde são feitas as requisições pra API, geralmente.
|
|
|
|
- **Screens (`organismo`)**: Organismos são componentes de IU complexos, compostos por grupos de moléculas e/ou átomos e/ou outros organismos. Esses organismos formam seções distintas de uma interface. Responsável pela a apresentação dos containers e interage com a navegação entre as telas. Possui pouca lógica/regra de negócio (menos do que o container). Onde são feitas as requisições pra API, geralmente.
|
|
|
|
|
|
|
|
### Diagramas de Componentes
|
|
|
|
|
| ... | ... | |
