{"id":201,"date":"2022-08-23T10:13:54","date_gmt":"2022-08-23T13:13:54","guid":{"rendered":"https:\/\/gerais.defensoria.mg.def.br\/metodologia-de-desenvolvimento\/?post_type=v1&p=201"},"modified":"2024-02-20T12:33:13","modified_gmt":"2024-02-20T15:33:13","slug":"padroes-arquiteturais","status":"publish","type":"v1","link":"https:\/\/gerais.defensoria.mg.def.br\/metodologia-de-desenvolvimento\/sumario\/padroes-arquiteturais\/","title":{"rendered":"Padr\u00f5es Arquiteturais"},"content":{"rendered":"

1 – BACKEND<\/strong><\/h4>\n
1.1 – JAVA<\/strong><\/h5>\n

Baseado na escalabilidade necess\u00e1ria para melhor funcionamento dos sistemas da DPMG, de forma integrada, foi definido a utiliza\u00e7\u00e3o do JAVA e toda sua stack para implementa\u00e7\u00f5es de aplica\u00e7\u00f5es robustas.
\nJava \u00e9 uma linguagem de programa\u00e7\u00e3o e plataforma computacional lan\u00e7ada pela pela Sun Microsystems em 1995. Existem muitas aplica\u00e7\u00f5es cujo funcionamento est\u00e3o condicionados \u00e0 presen\u00e7a do Java instalado. Java \u00e9 uma linguagem gratuita, est\u00e1 entre as linguagens mundialmente mais usadas e atualmente \u00e9 mantida pela Oracle.
\nPrincipais caracter\u00edsticas do Java:<\/p>\n

    \n
  • Suporte \u00e0 orienta\u00e7\u00e3o a objetos;<\/li>\n
  • Portabilidade;<\/li>\n
  • Seguran\u00e7a;<\/li>\n
  • Linguagem Simples;<\/li>\n
  • Alta Performance;<\/li>\n
  • Dinamismo;<\/li>\n
  • Interpretada (o compilador pode executar os bytecodes do Java diretamente em qualquer m\u00e1quina);<\/li>\n
  • Distribu\u00eddo;<\/li>\n
  • Independente de plataforma;<\/li>\n
  • Tipada (detecta os tipos de vari\u00e1veis quando declaradas).<\/li>\n<\/ul>\n

    Os sistemas comunicam entre si atrav\u00e9s de “cliente-servidor”, onde as aplica\u00e7\u00f5es frontends (cliente) realizam requisi\u00e7\u00f5es na API Gateway (servidor) para manipula\u00e7\u00f5es e consultas de dados. As API’s s\u00e3o respons\u00e1veis por receber as request de microsservi\u00e7os, validar o acesso aos endpoints via permiss\u00e3o do usu\u00e1rio, manipular o dado e retornar a informa\u00e7\u00e3o solicitada via response.
    \nOs microsservi\u00e7os possuem defini\u00e7\u00f5es a serem seguidas, como por exemplo a implementa\u00e7\u00e3o de rollbacks em todos os m\u00e9todos que utilize transa\u00e7\u00e3o. Tamb\u00e9m dever\u00e3o ser servi\u00e7os simples e objetivos. Todos os endpoints devem ser documentados atrav\u00e9s do Swagger e com o SCSDP corretamente configurado.<\/p>\n

    1.1.1 – REPRESENTA\u00c7\u00c3O ARQUITETURAL<\/strong><\/h6>\n

    \"img\"<\/p>\n

    1.1.2 – ARCHETYPE BACKEND DPMG<\/strong><\/h6>\n

    Esse projeto foi criado para facilitar a cria\u00e7\u00e3o de novos projetos JAVA na DPMG.<\/p>\n

    Todos os padr\u00f5es no desenvolvimento ser\u00e3o mantidos nesse projeto para melhorar a integra\u00e7\u00e3o de novos participantes na equipe e at\u00e9 mesmo a cria\u00e7\u00e3o de projetos no dia a dia.<\/p>\n

    Esse projeto s\u00f3 precisar\u00e1 ser clonado caso queira contribuir com o archetype, fora isso n\u00e3o \u00e9 necess\u00e1rio para cria\u00e7\u00e3o de novos projetos<\/p>\n

    1.1.3 – COMANDOS B\u00c1SICOS<\/strong><\/h6>\n

    Execute o comando na pasta onde deseja criar o projeto.<\/p>\n

    mvn archetype:generate -DarchetypeGroupId=br.def.mg.defensoria -DarchetypeArtifactId=archetype-backend -DarchetypeVersion=2.1.9 -Dprojeto=nome-projeto<\/p>\n

    Ps: Caso o settings do maven n\u00e3o esteja na pasta padr\u00e3o dever\u00e1 adicionar o seguinte atributo<\/p>\n

    -s \/diretorio\/arquivoSettings.xml<\/p>\n

    Ao gerar esse comando ser\u00e1 gerado um projeto maven multi-modules com a camada de persist\u00eancia e servi\u00e7o, um modulo de depend\u00eancias tamb\u00e9m ser\u00e1 gerado com as depend\u00eancias mais utilizadas nos projetos<\/p>\n

    1.1.4 – CONFIGURA\u00c7\u00c3O DO PROJETO<\/strong><\/h6>\n

    O projeto gerado ser\u00e1 montado com a seguinte Stack de tecnologias<\/p>\n

      \n
    • Java 17<\/li>\n
    • JPA<\/li>\n
    • EclipseLink<\/li>\n
    • Apache Commons 3.1<\/li>\n
    • Jakarta JAX-RS<\/li>\n
    • Jakarta EJB<\/li>\n
    • Swagger<\/li>\n
    • JUnit 5<\/li>\n
    • Lombook<\/li>\n
    • Integra\u00e7\u00e3o com SCSDP<\/li>\n
    • JACOCO<\/li>\n
    • Surefire reports<\/li>\n<\/ul>\n
      1.1.5 – DEPED\u00caNCIAS ENTRE PROJETOS<\/strong><\/h6>\n
        \n
      • dpmg-commons<\/li>\n
      • scsdp-commons<\/li>\n<\/ul>\n

        As configura\u00e7\u00f5es de charset e encode j\u00e1 ser\u00e3o realizadas.<\/p>\n

        O pacote de todos os modulos j\u00e1 definidos por padr\u00e3o com o seguinte valor:<\/p>\n

        br.def.mg.defensoria.nomeProjeto<\/p>\n

        O groupId \u00e9 definido pelo padr\u00e3o da defensoria:<\/p>\n

        br.def.mg.defensoria<\/p>\n

        Observa\u00e7\u00e3o: O pacote default gerado deve ser alterado caso o nome do projeto seja composto, alterando para nome.projeto n\u00e3o \u00e9 poss\u00edvel automatizar essa parte trocando “-” por “.”<\/p>\n

        1.1.6 – CONFIGURA\u00c7\u00c3O DO SONAR<\/strong><\/h6>\n

        Foi configurado os testes para conseguir analisar qual a porcentagem de coverage do c\u00f3digo fonte.<\/p>\n

        1.2 – ESTRUTURA<\/strong><\/h5>\n

        Baseado em organiza\u00e7\u00e3o dos c\u00f3digos para garantir melhor leitura e manuten\u00e7\u00e3o de servi\u00e7os, foi definido uma arquitetura de forma que seus m\u00f3dulos possuam baixo acoplamento<\/span><\/span>\u00a0<\/span>
        <\/span>entre si e de f\u00e1cil compreens\u00e3o, permitindo um desenvolvimento \u00e1gil.<\/span><\/span><\/p>\n

        A arquitetura base \u00e9 composta por 1 projeto \u201cpai\u201d que agrupa 4 projetos \u201cfilhos\u201d. Estes 4 projetos s\u00e3o definidos como m\u00f3dulos, e eles s\u00e3o separados em: <\/span>Dependencies<\/span>,<\/span> Migration<\/span>, <\/span>Persistence<\/span> e Service.<\/span> Em casos espec\u00edficos em que o projeto tenha automa\u00e7\u00f5es, poder\u00e1 ser inclu\u00eddo os m\u00f3dulos chamados de <\/span>Job<\/span> e <\/span>Shared<\/span>.<\/span><\/span>\u00a0<\/span><\/p>\n

        1.2.1 – DEPENDENCIES<\/strong><\/h6>\n

        Este modulo \u00e9 respons\u00e1vel por gerenciar as bibliotecas utilizadas pelos demais m\u00f3dulos da aplica\u00e7\u00e3o. A imagem abaixo \u00e9 um exemplo de como devem ser importadas as bibliotecas.<\/p>\n

        \"img\"<\/p>\n

        1.2.2 – MIRGRATION<\/strong><\/h6>\n

        O modulo de migration \u00e9 respons\u00e1vel pela gest\u00e3o dos scripts de banco de dados que dever\u00e3o ser executados para o correto funcionamento do m\u00f3dulo Persistence. Os scripts
        \ns\u00e3o organizados em pasta de estrutura e pasta de dados. Os dados devem ser separados por ambiente (Desenvolvimento, Homologa\u00e7\u00e3o e Produ\u00e7\u00e3o). Os scripts de estrutura
        \ns\u00e3o executados pelo flyway ao rodar a pipeline.<\/p>\n

        1.2.3 – PERSISTENCE<\/strong><\/h6>\n

        Este modulo \u00e9 respons\u00e1vel pelas classes Java de mapeamento objeto relacional das tabelas e seus relacionamentos. No persistence deve ter duas pastas, entities,
        \nonde ficam as entidades mapeadas, e enums, onde ficam os enumerados.<\/p>\n

        1.2.4 – SERVICE<\/strong><\/h6>\n

        Neste modulo cont\u00e9m todo o fluxo de desenvolvimento das regras de neg\u00f3cio da aplica\u00e7\u00e3o. \u00c9 nele que deve ser criado as Controllers (para servi\u00e7os REST), os DTOs
        \n(para objetos JSON), os EJB’s (para codifica\u00e7\u00f5es das regras de neg\u00f3cio) e os DAOs (para persistir ou buscar no banco de dados).<\/p>\n

        \"img\"<\/p>\n

        1.2.5 \u2013 JOB<\/span><\/b>\u00a0<\/span><\/h6>\n

        Este modulo <\/span>possibilita o agendamento de tarefas, as quais ser\u00e3o executadas em hor\u00e1rios pr\u00e9-definidos. Lembrando que este modulo dever\u00e1 existir somente em uma inst\u00e2ncia do WildFly, com isso evitar\u00e1 que as tarefas sejam executadas mais de uma vez devido as inst\u00e2ncias.<\/span>\u00a0<\/span><\/p>\n

        \"\"<\/p>\n

        1.2.6 \u2013 SHARED<\/span><\/b>\u00a0<\/span><\/h6>\n

        Seu objetivo \u00e9<\/span> evitar que o M\u00f3dulo Job tenha que fazer uma integra\u00e7\u00e3o para acessar a servi\u00e7os remotos dentro do projeto. Neste modulo \u00e9 utilizado JNDI (Java Naming and Directory Interface), que \u00e9 uma API que permite acesso \u00e0 recursos externos atrav\u00e9s de um nome utilizando o conceito de lookup.<\/span>\u00a0<\/span><\/p>\n

        \"\"<\/p>\n

        1.3 – DMPG-COMMONS<\/strong><\/h5>\n

        Projeto que centralizar as funcionalidades b\u00e1sicas de todos os sistemas.<\/p>\n

        1.3.1 – PARAMETROS UTIL<\/strong><\/h6>\n

        Utilizada para recupera os par\u00e2metros do sistema.<\/p>\n

        \"img\"<\/p>\n

        1.3.2 – DPMG API UTIL<\/strong><\/h6>\n

        Classe utilit\u00e1ria para a realiza\u00e7\u00e3o de integra\u00e7\u00f5es<\/p>\n

        1.3.2.1 – DEPEND\u00caNCIA<\/strong><\/h6>\n

        \"\"<\/p>\n

        1.3.2.2 – EXEMPLOS<\/strong><\/h6>\n
          \n
        • Requisi\u00e7\u00f5es do tipo GET<\/li>\n<\/ul>\n

          \"img\"<\/p>\n

            \n
          • Para adicionar query param:<\/li>\n<\/ul>\n

            \"img\"<\/p>\n

              \n
            • Para ignorar a resposta:<\/li>\n<\/ul>\n

              \"img\"<\/p>\n

                \n
              • Requisi\u00e7\u00f5es tipo POST<\/li>\n<\/ul>\n

                \"img\"<\/p>\n

                Onde:<\/p>\n\n\n\n\n\n\n\n
                Par\u00e2metro<\/strong><\/th>\nTipo dado<\/strong><\/th>\nDefault<\/strong><\/th>\nExemplo<\/strong><\/th>\n<\/tr>\n<\/thead>\n
                URL<\/td>\nString<\/td>\n<\/td>\nhttp:\/\/dev-10.230.16.76\/unidade\/find-all<\/a><\/td>\n<\/tr>\n
                TIMEOUT (segundos)<\/td>\nint<\/td>\n5<\/td>\n10<\/td>\n<\/tr>\n
                OBJETO<\/td>\nObject<\/td>\n<\/td>\nnew Usuario()<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
                  \n
                • Para retornar uma resposta do tipo text\/plain :<\/li>\n<\/ul>\n

                  \"img\"<\/p>\n

                    \n
                  • Requisi\u00e7\u00f5es tipo PUT<\/li>\n<\/ul>\n

                    \"img\"<\/p>\n

                    Onde:<\/p>\n\n\n\n\n\n\n\n
                    Par\u00e2metro<\/strong><\/th>\nTipo dado<\/strong><\/th>\nDefault<\/strong><\/th>\nExemplo<\/strong><\/th>\n<\/tr>\n<\/thead>\n
                    URL<\/td>\nString<\/td>\n<\/td>\nhttp:\/\/dev-10.230.16.76\/unidade\/find-all<\/a><\/td>\n<\/tr>\n
                    TIMEOUT (segundos)<\/td>\nint<\/td>\n5<\/td>\n10<\/td>\n<\/tr>\n
                    OBJETO<\/td>\nObject<\/td>\n<\/td>\nnew Usuario()<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
                      \n
                    • Requisi\u00e7\u00f5es tipo DELETE<\/li>\n<\/ul>\n

                      \"img\"<\/p>\n

                      Onde:<\/p>\n\n\n\n\n\n\n
                      Par\u00e2metro<\/strong><\/th>\nTipo dado<\/strong><\/th>\nDefault<\/strong><\/th>\nExemplo<\/strong><\/th>\n<\/tr>\n<\/thead>\n
                      URL<\/td>\nString<\/td>\n<\/td>\nhttp:\/\/dev-10.230.16.76\/unidade\/find-all<\/a><\/td>\n<\/tr>\n
                      TIMEOUT (segundos)<\/td>\nint<\/td>\n5<\/td>\n10<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
                        \n
                      • Para adicionar token na requisi\u00e7\u00e3o<\/li>\n<\/ul>\n

                        \"img\"<\/p>\n

                        Onde:<\/p>\n\n\n\n\n\n
                        Par\u00e2metro<\/th>\nTipo dado<\/th>\nDefault<\/th>\nExemplo<\/th>\n<\/tr>\n<\/thead>\n
                        TOKEN<\/td>\nString<\/td>\n<\/td>\nBearer eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkJydW5vIiwiaWF0IjoxNTE2MjM5MDIyfQ.YDN0wJHLzyzmqdwycv4wgh-RMBwQR4C_0uehWmo_77ZrAB46YnPYmzJJ2Lb36GyyDXDwRP9Bt759hcVmUiGWEg<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

                        2 – PADR\u00c3O DE ARQUITETURA FRONT-END<\/strong><\/h4>\n

                        Os projetos Front-End da institui\u00e7\u00e3o DPMG e baseado no padr\u00e3o de arquitetura \u201cMVC\u201d que melhora a conex\u00e3o entre camadas de dados regras de neg\u00f3cio e a intera\u00e7\u00e3o com usu\u00e1rio,
                        \ntamb\u00e9m seguimos os princ\u00edpios do \u201cSOLID\u201ccom \u00eanfase nos dois primeiros princ\u00edpios \u201cS – Single-responsibility Principle (Princ\u00edpio da responsabilidade \u00fanica)\u201d e
                        \n\u201cO – Open-closed Principle (Princ\u00edpio do aberto-fechado)\u201d.<\/strong><\/p>\n

                        O padr\u00e3o para criar aplica\u00e7\u00f5es VueJS v2.x e o \u201cclass component\u201d que \u00e9 estendido da pasta \u201cdata\u201d, j\u00e1 no VueJS v3.x utilizamos o composition api o arquivo da pasta \u201cdata\u201d e
                        \ndeclarado como uma constante.<\/p>\n

                        Exemplo imagem VueJS v2.x e v3.x:<\/p>\n

                        VueJS 2:<\/p>\n

                        \"img\"<\/p>\n

                        VueJS 3:<\/p>\n

                        \"img\"<\/p>\n

                        2.2 – PLUGINS<\/strong><\/h6>\n

                        As rotas s\u00e3o definidas com plugin vue-router para VueJS v2.x e v3.x.
                        \nO plugin de armazenamento de estado para VueJS v2.x e vuex, enquanto no VueJS v3.x e o Pinia.
                        \nO vue-i18n plugin de internacionaliza\u00e7\u00e3o do VueJS utilizado somente nas vers\u00f5es 3.x do vue.
                        \nOs plugins de front-end utilizados s\u00e3o Vuetify para VueJS v2.x e Quasar para v3.x.<\/p>\n

                        Os plugins para cria\u00e7\u00e3o de formul\u00e1rios para vers\u00e3o 3.x do Vue, ser\u00e1 o Vee-validate em conjunto com Yup e Pinia.<\/p>\n

                        2.3 – REGRAS PARA CRIA\u00c7\u00c3O DE PASTAS E ARQUIVOS<\/strong><\/h5>\n

                        Todas as pastas e arquivos s\u00e3o criados com letras min\u00fasculas e separadas com h\u00edfen.
                        \nTodos arquivos com fun\u00e7\u00f5es especificas como entity devem ser terminados com ponto seguido do nome da pasta, somente no caso de arquivos typescript.
                        \nToda estrutura pode sofre adi\u00e7\u00f5es de pasta como \u201cassets\u201d, \u201cutil\u201d ou \u201c@types\u201d entre outras necess\u00e1rias para facilitar o desenvolvimento, por\u00e9m sempre
                        \nmantendo a estrutura base e seguindo os padr\u00f5es estabelecidos.<\/p>\n

                        2.3.1 – ESTRUTURA DE PASTA<\/strong><\/h6>\n
                          \n
                        • Root<\/strong> \u2013 Arquivos contendo vari\u00e1veis de ambiente, configura\u00e7\u00f5es de lint entre outros arquivos b\u00e1sicos dependendo da aplica\u00e7\u00e3o.<\/li>\n
                        • Src<\/strong> \u2013 Arquivos e pastas e iram compor o sistema.<\/li>\n
                        • Controllers<\/strong> \u2013 Arquivos e pastas respons\u00e1veis por intermediar as requisi\u00e7\u00f5es enviadas pela camada de intera\u00e7\u00e3o com usu\u00e1rio.<\/li>\n
                        • Config<\/strong> \u2013 Todos os arquivos que definem configura\u00e7\u00f5es ou meios de acesso a aplica\u00e7\u00f5es externas.<\/li>\n
                        • Services<\/strong> \u2013 Todos os arquivos que conectam a API\u2019s.<\/li>\n
                        • Plugins<\/strong> \u2013 Todos os arquivos que que fazem altera\u00e7\u00f5es no software permitindo utiliza\u00e7\u00e3o de fermentas externas como Quasar ou Vuetify.<\/li>\n
                        • Models<\/strong> \u2013 Arquivos e pastas que controlam a forma como os dados se comportam por meio das fun\u00e7\u00f5es, l\u00f3gica e regras de neg\u00f3cios estabelecidas.<\/li>\n
                        • Entity<\/strong> \u2013 Todas os arquivos que se referem a entidades pr\u00e9-estabelecidas pela regra de neg\u00f3cio.<\/li>\n
                        • Shared<\/strong> \u2013 Todas os arquivos que definem implementa\u00e7\u00f5es obrigat\u00f3rias com base nas regras definidas.<\/li>\n
                        • Views<\/strong> \u2013 Arquivos e pastas respons\u00e1veis por apresentar informa\u00e7\u00f5es de forma visual ao usu\u00e1rio.<\/li>\n
                        • Pages<\/strong> \u2013 Todos os arquivos .vue que iram receber uma rota de acesso.<\/li>\n
                        • Components<\/strong> \u2013 Todos os arquivos .vue que n\u00e3o recebem uma rota ou s\u00e3o amplamente utilizados no c\u00f3digo.<\/li>\n
                        • Data<\/strong> \u2013 Todos arquivos .ts que ofereceram suporte aos componentes .vue fazendo a comunica\u00e7\u00e3o com controller, quando
                          \nutilizamos o framework Vue v2.x todos os componentes ser\u00e3o classes abstratas, no caso do Vue v3.x ser\u00e3o apenas classes.<\/li>\n
                        • Styles<\/strong> \u2013 Folhas de estilo .scss ou .css ser\u00e3o utilizadas por todo aplica\u00e7\u00e3o ou apenas um componente especifico.<\/li>\n<\/ul>\n

                          Exemplo na imagem abaixo.<\/p>\n

                          \"img\"<\/p>\n

                          2.4 – CONFIGURA\u00c7\u00d5ES FRONT-END<\/strong><\/h5>\n
                            \n
                          • Ecma-version ES2021, ES2020<\/li>\n
                          • Typescript<\/li>\n
                          • Vite (Apenas Vue v3.x)<\/li>\n
                          • Vue-i18n (Apenas Vue v3.x)<\/li>\n
                          • Vee-Validate (Apenas Vue v3.x)<\/li>\n
                          • Yup (Apenas Vue v3.x)<\/li>\n
                          • Quasar (Apenas Vue v3.x))<\/li>\n
                          • Pinia (Apenas Vue v3.x))<\/li>\n
                          • Vuetify (Apenas Vue v2.x)<\/li>\n
                          • Vuex (Apenas Vue v2.x)<\/li>\n
                          • Vue-router<\/li>\n
                          • Eslint<\/li>\n
                          • Prettier<\/li>\n
                          • Sass (utilizamos o scss)<\/li>\n<\/ul>\n
                            2.5 – PALETA DE CORES<\/strong><\/h5>\n

                            \"img\"<\/p>\n

                            3 – MOBILE<\/strong><\/h4>\n
                              \n
                            • Os projetos mobiles devem ser com Flutter (vers\u00e3o atual 3.0.5);<\/li>\n
                            • A linguagem para desenvolvimento Flutter \u00e9 o Dart (vers\u00e3o atual 2.17.6);<\/li>\n
                            • O ambiente deve possuir o JDK 8, para a execu\u00e7\u00e3o do SDK;<\/li>\n
                            • A vers\u00e3o do Android SDK deve ser 32.1.0-rc1 ;<\/li>\n
                            • As bibliotecas utilizadas no padr\u00e3o\/estrutura BLoC s\u00e3o 8.0.1;<\/li>\n<\/ul>\n

                              \u00c9 importante que os layouts, bot\u00f5es, fontes e \u00edcones estejam de acordo com a Paleta de Cor da DPMG.<\/p>\n

                              \"img\"<\/p>\n

                              Partes de telas que ser\u00e3o utilizadas em mais de um lugar, dever\u00e3o ser componentizadas, para tornar a manutenibilidade mais eficaz;<\/p>\n

                              3.2 – CLEAN ARCHITECTURE<\/strong><\/h5>\n

                              As aplica\u00e7\u00f5es de m\u00e9dia e grande complexidade v\u00eam tomando a Clean Architecture como uma das melhores solu\u00e7\u00f5es, de modo a criar uma arquitetura que seja facilmente escal\u00e1vel, test\u00e1vel e manuten\u00edvel. Sendo assim, entendemos ser a melhor op\u00e7\u00e3o para aplicar nos projetos mobiles da DPMG.<\/p>\n

                              \"img\"<\/p>\n

                              3.2.1 – AS CAMADAS DO APP COM CLEAN ARCHITECTURE<\/strong><\/h6>\n

                              A arquitetura se divide basicamente, nas seguintes camadas:<\/p>\n

                              API \/ Local \/ DB \u2192 Remoto \/ Local (DataSource) \u2192 Reposit\u00f3rio \u2192 Casos de Uso \u2192 BLoC \u2192 View<\/strong><\/p>\n

                              A arquitetura segue as regras de que, cada camada deve se comunicar apenas com seu componente imediato, desta forma, segue conforme o esquema abaixo:<\/p>\n

                                \n
                              • A UI (User Interface) pode se comunicar somente, com a ViewModel;<\/li>\n
                              • O BLoC pode se comunicar somente, com o UseCase;<\/li>\n
                              • O UseCase pode se comunicar somente, com o Repository;<\/li>\n
                              • O Repository pode se comunicar somente, com a DataSource.<\/li>\n<\/ul>\n
                                3.2.2 – CAMADA DE APRESENTA\u00c7\u00c3O (PRESENTATION LAYER)<\/strong><\/h6>\n

                                S\u00e3o representadas nesta camada, pelas Views e BLoC:<\/p>\n

                                \"img\"<\/p>\n

                                  \n
                                • A View \u00e9 constru\u00edda, utilizando o conceito de Widgets no Flutter, que descrevem como a interface visual deve ser representado, dado sua configura\u00e7\u00e3o e estado;<\/li>\n
                                • O BLoC possui regras de neg\u00f3cio e \u00e9 desenvolvida com objetivo de armazenar e gerenciar os dados, sendo eles recebidos
                                  \npor meio de requisi\u00e7\u00f5es de API, banco de dados, etc.<\/li>\n<\/ul>\n
                                  3.2.3 – CAMADA DE DOM\u00cdNIO (DOMAIN LAYER)<\/strong><\/h6>\n

                                  A composi\u00e7\u00e3o desta camada, \u00e9 feita pelos UseCases e Repositories:<\/p>\n

                                  \"img\"<\/p>\n

                                    \n
                                  • O UseCase \u00e9 respons\u00e1vel por orquestrar o fluxo de dados das entidades e o direcionar para a regra de neg\u00f3cio, com a finalidade de atingir os objetivos que este \u00e9 respons\u00e1vel;<\/li>\n
                                  • O Repository tem o objetivo de executar a l\u00f3gica de acesso aos dados, sua responsabilidade \u00e9 de obter e verific\u00e1-los
                                    \nonde est\u00e3o, e decidir onde procurar a cada momento.<\/li>\n<\/ul>\n
                                    3.2.4 – CAMADA DE DADOS (DATA LAYER)<\/strong><\/h6>\n

                                    \"img\"<\/p>\n

                                    Nesta camada se encontram os dados e de onde eles podem ser acessados.<\/p>\n

                                    O DataSource \u00e9 a fonte de dados propriamente dita, ou seja, \u00e9 o que a implementa\u00e7\u00e3o executa, para acessar os dados.<\/p>\n

                                    4 – DOCUMENTO ARQUITETURA DE SOFTWARE \u2014 NODE JS<\/strong><\/h4>\n

                                    O node e utilizado como microsservi\u00e7os e websockets, a vers\u00e3o do node e a v18.x\/v20.x. Framework escolhido para trabalhar com mesmo foi NestJS pois ele tem como proposta
                                    \nfacilitar o desenvolvimento de aplica\u00e7\u00f5es back-end independente do protocolo de comunica\u00e7\u00e3o que elas utilizem, segundo fator e sua documenta\u00e7\u00e3o que nos traz diferentes
                                    \nformas de estruturar a aplica\u00e7\u00e3o NestJS al\u00e9m de ser rica em detalhes e exemplos, a tornando de f\u00e1cil entendimento. O ORM escolhido foi \u00a0o Prisma. Toda projeto desenvolvido deve possuir documenta\u00e7\u00e3o que e gerada com Swagger. Parte de seguran\u00e7a foi gerar com guard\u2019s que e mesmo conceito dos \u201cguard\u2019s\u201d
                                    \ndo Angular. O desenvolvimento e baseado na arquitetura \u201cMVC\u201d sendo aplicado tamb\u00e9m os conceitos do \u201cS.O.L.I.D\u201d.<\/p>\n

                                    4.1 – REGRAS PARA GERA\u00c7\u00c3O DA APLICA\u00c7\u00c3O<\/strong><\/h5>\n
                                      \n
                                    • Aplica\u00e7\u00f5es devem ser criadas com NestJS, em casos extraordin\u00e1rios onde n\u00e3o se possa gerar uma aplica\u00e7\u00e3o por qualquer
                                      \nlimita\u00e7\u00e3o t\u00e9cnica ou estrutural deve ser autorizada pelo gestor.<\/li>\n
                                    • O \u201cORM\u201d utilizado por padr\u00e3o e o Prisma.<\/li>\n
                                    • Aplica\u00e7\u00e3o deve contemplar o m\u00e1ximo poss\u00edvel dos conceitos do \u201cS.O.L.I.D\u201d.<\/li>\n
                                    • Toda aplica\u00e7\u00e3o desenvolvida com node deve ser microsservi\u00e7o ou websocket.<\/li>\n
                                    • Toda pasta com composi\u00e7\u00f5es de nome devem ser separados com h\u00edfen.<\/li>\n
                                    • Toda pasta a partir da pasta \u201csrc\u201d pode implementar pastas utilit\u00e1rias, desde que a mesma seja coesa em sua cria\u00e7\u00e3o.<\/li>\n
                                    • Toda aplica\u00e7\u00e3o deve ser protegida com Throttler do NestJs, caso aplica\u00e7\u00e3o n\u00e3o seja feita com o framework deve ser adotar uma solu\u00e7\u00e3o do mesmo tipo.<\/li>\n<\/ul>\n
                                      4.2 – ESTRUTURA DE PASTA<\/strong><\/h5>\n
                                        \n
                                      • Root<\/strong> \u2013 Onde ficam configura\u00e7\u00f5es, b\u00e1sicas como arquivos \u201cenv\u201d, \u201clint\u201d entre outros.<\/li>\n
                                      • Src<\/strong> \u2013 Onde a estrutura da aplica\u00e7\u00e3o ser\u00e1 gerada \u201ccontrollers\u201d, \u201cmodels\u201d e \u201cswagger\u201d tamb\u00e9m e poss\u00edvel criar pastas auxiliares.\n
                                          \n
                                        • Controllers<\/strong> \u2013 Aqui ficam os respons\u00e1veis por gerenciar a aplica\u00e7\u00e3o contendo pastas para servi\u00e7os com seguran\u00e7a, banco de dados e chamados do client-side.\n
                                            \n
                                          • Controllers –<\/strong> Esta pasta cont\u00e9m os controladores do aplicativo NestJS, que s\u00e3o respons\u00e1veis por lidar com as requisi\u00e7\u00f5es HTTP, processar dados e retornar respostas adequadas.<\/li>\n
                                          • Services<\/strong> \u2013 Servi\u00e7o que receber\u00e1 chamados do client-side, cada service cria uma pasta com nome do servi\u00e7o, gerando um aquivo \u201c.module\u201d e \u201c.service\u201d obrigatoriamente, caso necess\u00e1rio pode receber uma pasta \u201cdto\u201d ou outras pastas auxiliares com m\u00e1ximo de um n\u00edvel. Uma \u201cservice\u201d pode ou n\u00e3o implementar um \u201cguard\u201d.<\/li>\n
                                          • Models<\/strong> \u2013 Aqui ficam os itens referentes a regra de neg\u00f3cio.\n
                                              \n
                                            • Shared<\/strong> \u2013 Conte\u00fado obrigat\u00f3rio a ser implementado pelas entidades ou qualquer item que contenha regra de neg\u00f3cio pr\u00e9-definida.<\/li>\n
                                            • Entity<\/strong> \u2013 Entidades com base nas abstra\u00e7\u00f5es, implementam os itens referentes a mesma contidos na pasta \u201cshared\u201d.<\/li>\n
                                            • Dto – <\/strong>Cont\u00e9m classes ou interfaces que definem a estrutura dos dados transferidos entre diferentes partes do aplicativo, como requisi\u00e7\u00f5es HTTP e respostas.<\/li>\n<\/ul>\n<\/li>\n
                                            • Modules – <\/strong>Cont\u00e9m os m\u00f3dulos do aplicativo NestJS, que agrupam funcionalidades relacionadas, como rotas, controladores, provedores de servi\u00e7os e outros recursos.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n

                                              Exemplo da estrutura de pasta:<\/p>\n

                                              \"\"<\/p>\n

                                              4.3 – TECNOLOGIAS<\/strong><\/h5>\n
                                                \n
                                              • Ecmaversion 2021, 2020.<\/li>\n
                                              • Typescript<\/li>\n
                                              • Node v18.x\/v20.x<\/li>\n
                                              • NestJs<\/li>\n
                                              • Prisma<\/li>\n<\/ul>\n","protected":false},"featured_media":0,"parent":0,"menu_order":5,"template":"","class_list":["post-201","v1","type-v1","status-publish","hentry"],"acf":[],"_links":{"self":[{"href":"https:\/\/gerais.defensoria.mg.def.br\/metodologia-de-desenvolvimento\/wp-json\/wp\/v2\/v1\/201","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/gerais.defensoria.mg.def.br\/metodologia-de-desenvolvimento\/wp-json\/wp\/v2\/v1"}],"about":[{"href":"https:\/\/gerais.defensoria.mg.def.br\/metodologia-de-desenvolvimento\/wp-json\/wp\/v2\/types\/v1"}],"wp:attachment":[{"href":"https:\/\/gerais.defensoria.mg.def.br\/metodologia-de-desenvolvimento\/wp-json\/wp\/v2\/media?parent=201"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}