Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • W Wiki
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • EasyWork
  • Wiki
  • Wiki
  • 7. arquitetura

7. arquitetura · Changes

Page history
Update 7. arquitetura authored Jun 08, 2019 by Diego Osmarin Basso's avatar Diego Osmarin Basso
Hide whitespace changes
Inline Side-by-side
7.-arquitetura.md
View page @ a221a20e
...@@ -21,7 +21,7 @@ ...@@ -21,7 +21,7 @@
- Para a implantação do sistema (deploy) utiliza-se <a href="https://www.docker.com/">**Docker**</a>, uma tecnologia de software que permite que a utilização contêineres (virtualizações em nível de sistema operacional) que empacotam uma aplicação e suas dependências em um recipiente virtual. - Para a implantação do sistema (deploy) utiliza-se <a href="https://www.docker.com/">**Docker**</a>, uma tecnologia de software que permite que a utilização contêineres (virtualizações em nível de sistema operacional) que empacotam uma aplicação e suas dependências em um recipiente virtual.
- Mais precisamente, utiliza-se <a href="https://docs.docker.com/compose/overview/">**Docker Compose**</a>, uma ferramenta que define e implementa um ambiente contendo múltiplos contêiners Docker. - Mais precisamente, utiliza-se <a href="https://docs.docker.com/compose/overview/">**Docker Compose**</a>, uma ferramenta que define e implementa um ambiente contendo múltiplos contêiners Docker.
- Abaixo encontra-se o diagrama de microsserviços onde: - Abaixo encontra-se o diagrama de microsserviços onde:
* a caixa em branco representa o usuário do sistema, tipicamente um browse web. * a caixa em branco representa o usuário do sistema, tipicamente um browser web.
* as caixas em azul representam as aplicações dockerizadas e implementadas no projeto. * as caixas em azul representam as aplicações dockerizadas e implementadas no projeto.
* as caixas em cinza representam as aplicações não implementadas no projeto, podendo fazer parte de um futuro MVP. * as caixas em cinza representam as aplicações não implementadas no projeto, podendo fazer parte de um futuro MVP.
...@@ -31,14 +31,14 @@ ...@@ -31,14 +31,14 @@
## 7.5 Análise dos princípios SOLID ## 7.5 Análise dos princípios SOLID
#### Single Responsibility Principle: #### Single Responsibility Principle:
O projeto possui três microsserviços separados em características macro: autenticação, pesquisas e respostas. - O projeto possui três microsserviços separados em características macro: autenticação, pesquisas e respostas.
Cada microsserviço possui pacotes específicos para segurança, modelo de dados, comunicação com o banco de dados, modelo de saída, controladores e serviços. - Cada microsserviço possui pacotes específicos para segurança, modelo de dados, comunicação com o banco de dados, modelo de saída, controladores e serviços.
Os controladores estão definidos conforme as rotas disponibilizadas, implementam um método para cada rota específica e delegam o processamento para os métodos de serviço. - Os controladores estão definidos conforme as rotas disponibilizadas, implementam um método para cada rota específica e delegam o processamento para os métodos de serviço.
#### Open Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, Dependency Inversion Principle: #### Open Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, Dependency Inversion Principle:
O projeto possui uma lógica concisa, direta e enxuta, logo suas classes não precisam de adptações, porém podem ser estendidas quando necessário. - O projeto possui uma lógica concisa, direta e enxuta, logo suas classes não precisam de adptações, porém podem ser estendidas quando necessário.
Novas rotas e serviços podem ser facilmente criados com base nos já disponibilizados, sendo necessário apenas definição dos endpoints e da regra de negócio. - Novas rotas e serviços podem ser facilmente criados com base nos já disponibilizados, sendo necessário apenas definição dos endpoints e da regra de negócio.
O projeto se vale de diversas abstrações, interfaces e anotações providas pelo framework Spring e outros terceiros, assim trata-se de uma implementação que segue boas práticas consolidadas no mercado, que possui fácil manutenção e extensão, e que pratica grande reúso. - O projeto se vale de diversas abstrações, interfaces e anotações providas pelo framework Spring e outros terceiros, assim trata-se de uma implementação que segue boas práticas consolidadas no mercado, que possui fácil manutenção e extensão, e que pratica grande reuso.
<br><br> <br><br>
## 7.6 Segurança ## 7.6 Segurança
......
Clone repository
  • 1. home
  • 2. cronograma
  • 3. time
  • 4. pivotal labs
  • 5. requisitos
  • 6. mockups de tela
  • 7. arquitetura
  • 8. modelagem de dados
  • 9. rotas api
  • :10. tutorial de instalacao do projeto
  • :11. tecnologias
  • Home