Ir para o conteúdo

Referências

A plataforma TOTVS Apps foi construída com base em conceitos, princípios, práticas, estilos e padrões arquiteturais aplicados à construção de aplicações modernas.

Os próximos tópicos listam esses principais conceitos que são utilizados como referência para construção da plataforma TOTVS Apps e de suas aplicações.

Arquiteturas evolucionárias

Uma arquitetura evolucionária oferece suporte à construção de sistemas que permitem que arquitetos e desenvolvedores façam mudanças radicais nas partes mais importantes de seus sistemas com confiança. Abrange práticas que permitem aos desenvolvedores construir arquiteturas contínuas, que evoluem de forma limpa, sem a necessidade de uma bola de cristal.

Onde se atende e se procura ter:

  • Funções de Aptidão: Uma função de aptidão arquitetônica fornece uma avaliação de integridade objetiva de algumas características arquitetônicas;
  • Engenharia da Mudança Incremental: Uma arquitetura evolucionária oferece suporte à mudança incremental guiada em várias dimensões;
  • Acoplamento: A arquitetura evolucionária se concentra no acoplamento apropriado - de como identificar quais dimensões da arquitetura devem ser acopladas para fornecer o máximo de benefício com despesas e custos mínimos;
  • Dados Evolucionários: O design evolucionário em bancos de dados ocorre quando os desenvolvedores podem construir e desenvolver a estrutura do banco de dados conforme os requisitos mudam com o tempo;
  • Anti-padrões: Passamos muito tempo discutindo os níveis adequados de acoplamento em arquiteturas. No entanto, também vivemos no mundo real e vemos muitos acoplamentos que prejudicam a capacidade de evolução de um projeto;

Cloud Native

Aplicações construídas de forma escalável e distribuída, que se aproveitam do modelo de entrega e execução da computação em núvem

Conceitos como os citados abaixo, exemplificam esse modelo de arquitetura e construção de aplicações:

  • Containers:

    Contêineres são uma unidade de software padronizada que empacota código-fonte e todas as suas dependências de modo que a aplicação possa ser executada de forma rápida e confiável de um ambiente computacional para outro.

    Rede Física
    Rede Física
    Orquestrador
    Orquestrador
    Infraestrutura
    Infraestrutura
    Sistema Operacional
    Sistema Operacional
    Executor de contêiner
    Executor de contêiner
    Contêiner 1
    Contêiner 1
    Mestre
    Mestre
    Contêiner 2
    Contêiner 2
    Contêiner X
    Contêiner X
    Nó 1
    Nó 1
    Infraestrutura
    Infraestrutura
    Sistema Operacional
    Sistema Operacional
    Executor de contêiner
    Executor de contêiner
    Contêiner 1
    Contêiner 1
    Contêiner 2
    Contêiner 2
    Contêiner Y
    Contêiner Y
    Nó 2
    Nó 2
    Infraestrutura
    Infraestrutura
    Sistema Operacional
    Sistema Operacional
    Executor de contêiner
    Executor de contêiner
    Contêiner 1
    Contêiner 1
    Contêiner 2
    Contêiner 2
    Contêiner Z
    Contêiner Z
    Nó 3
    Nó 3
    Text is not SVG - cannot display

  • Microsserviços:

    Uma arquitetura de microsserviço é um estilo de arquitetura que estrutura uma aplicação como uma coleção de serviços que são:

    - Implantado independentemente; - Pertencente a um time pequeno; - Organizado através de capacidades de negócio; - Com baixo acoplamento; - Altamente manutenível e testável;

    Essa arquitetura permite uma entrega rápida, frequente e confiável de aplicações complexas. Permitindo também que a organização evolua sua stack de tecnologia.

    Granularidade decrescente
    Granularidade decrescente
    Macrosserviço
    Macrosserviço
    Minisserviço
    Minisserviço
    Microsserviço
    Microsserviço
    Aplicação
    Aplicação
    Capacidade
    Capacida...
    Domínio
    Domínio
    Funcionalidade
    Funcionalidade
    Comércio Eletrônico
    Comércio...
    Pedido
    Pedido
    Carrinho de Compra
    Carrinho...
    Forma de Entrega
    Forma de Entr...
    Text is not SVG - cannot display

  • Service mesh:

    Service Mesh é uma infraestrutura distribuída de software que lida com a comunicação entre os microsserviços, entregando mensagens de forma confiável e segura e acrescentando a essa comunicação visibilidade e recursos de controle e gerenciamento. Normalmente implementada através de sidecars que fazem o papel de proxy de comunicação entre as aplicações e da aplicação com o mundo externo.

    Nó 1
    Nó 1
    Controlador
    Controlador
    Serviço 1
    Serviço 1
    Contêiner 1
    Contêiner 1
    Sidecar
    Sidecar
    Nó 2
    Nó 2
    Serviço 2
    Serviço 2
    Contêiner 2
    Contêiner 2
    Sidecar
    Sidecar
    Text is not SVG - cannot display

  • APIs declarativas:

    IMPERATIVO ("como fazer as alterações")
    IMPERATIVO ("como fazer as alterações")
    API
    API
    Cliente
    Cliente
    Back-end
    Back-end
    "Altere isso, aquilo e aquele outro"
    "Altere isso, aquilo e aquele outro"
    Recurso
    Recurso
    Cliente
    Cliente
    Back-end
    Back-end
    "Aqui está o que preciso, faça acontecer"
    "Aqui está o que preciso, faça acontecer"
    DECLARATIVO ("aqui estão as mudanças que quero fazer")
    DECLARATIVO ("aqui estão as mudanças que quero fazer")
    Text is not SVG - cannot display

  • Infraestrutura imutável:

    Uma infraestrutura imutável é um modelo onde nenhuma atualização, patch de segurança ou mudança de configuração acontece "localmente" em um sistema em produção. Se alguma mudança é necessária, uma nova versão da arquitetura é construída e implantada em produção, sempre baseado em códigos-fonte e automação.

Princípios e práticas

Aplicações que seguem princípios e práticas que procuram manter a arquitetura limpa e reconhecível, através da aplicação de:

  • Clean Architecture

    Separação de responsabilidades das camadas e blocos de um sistema de software;

    clean-architecture

  • Domain Driven Design

    Onde:

    - O foco primário do software é atender o coração do negócio e suas regras de negócio; - A linguagem utilizada pelo sistema de software segue a mesma linguagem utilizada pelo negócio; - A complexidade do negócio é colocada em modelos de domínio.

    <<Context Map>>
    Domínio de RH
    <<Context Map>>...
      <<Bounded Context>>  
      Gestão de Pré-requisitos  
    <<Bounded Context>>...
      <<Bounded Context>>  
      Recrutamento  
    <<Bounded Context>>...
      <<Bounded Context>>  
      Base de Candidatos  
    <<Bounded Context>>...
    U
    U
    Microservices Decomposition
    Microservices Decomposition
    U
    U
    <<Microservice>>
    Gestão de 
    Políticas

    <<Microservice>>...
    support
    support
    U
    U
    D
    D
    <<Microservice>>
    Avaliação de Candidato
    <<Microservice>>...
    core
    core
    D
    D
    ACL
    ACL
    D
    D
    <<Microservice>>
    Pré Qualificação
     & Triagem

    <<Microservice>>...
    D
    D
    core
    core
    <<Microservice>>
    Ofertas de Emprego
    <<Microservice>>...
    core
    core
    D
    D
    ACL
    ACL
    D
    D
    ACL
    ACL
    U
    U
    <<Microservice>>
    Prospecção
    <<Microservice>>...
    core
    core
    D
    D
    ACL
    ACL
    <<Microservice>>
    Gerenciamento
    de Entrevistas & Seleção

    <<Microservice>>...
    core
    core
    D
    D
    <<Microservice>>
    Gestão de
    Candidatos

    <<Microservice>>...
    generic
    generic
    U
    U
    OHS / PL
    OHS / PL
    Text is not SVG - cannot display

  • Teorema CAP

    Entende-se da relação entre consistência, disponibilidade e tolerância a partição;

    C
    C
    P
    P
    A
    A
    Consistência
    Consistência
    Disponibilidade
    Disponibilidade
    Tolerância a partição
    Tolerância a pa...
    Categoria CP
    Há o risco de algum dado não estar disponível.
    Ex: MondoDB, Hbase, Memcache, BigTable, Redis
    Categoria CP...
    Categoria CA
    Algum problema de rede pode parar o sistema.
    Ex: RDBMS (Oracle, SQL Server, MySQL, PostgreSQL)
    Categoria CA...
    Categoria AP
    Cliente podem ler dados inconsistentes.
    Ex: Cassandra, RIAK, CouchDB
    Categoria AP...
    Escolha dois
    Escolh...
    Text is not SVG - cannot display

  • Princípios SOLID

    ingle Responsibility Principle
    Uma classe deve somente ter uma responsabilidade, ou seja, somente uma alteração poderia ser feita e assim afetar sua especificação.
    ingle Responsibility Principle...
    pen / Closed Principle
    Um elemento de software (classe, módulo, etc) 
    deve estar aberto a extensões mas deve estar fechado para modificações.
    pen / Closed Principle...
    iskov Substitution Principle
    Objetos em um programa podem ser substituídos por outras instâncias do seu sub-tipo sem que isso altere seu correto comportamento.
    iskov Substitution Principle...
    nterface Segregation Principle
    Clientes não devem ser forçados a depender de interfaces que eles não utilizam.
    nterface Segregation Principle...
    ependency Inversion Principle
    Desenvolva baseado em interfaces e não em implementações.
    ependency Inversion Principle...
    S
    S
    O
    O
    L
    L
    I
    I
    D
    D
    Text is not SVG - cannot display

  • Os Doze Fatores

    I. Base de Código
    Uma base de código com rastreamento utilizando controle de revisão e muitos deploys
    I. Base de Código...
    II. Dependência
    Declare e isole as dependências
    II. Dependência...
    III. Configurações
    Armazene as configurações no ambiente
    III. Configurações...
    IV. Serviço de Apoio
    Trate os serviços de apoio, como recursos ligados
    IV. Serviço de Apoio...
    V. Build, Release, Run
    Separe estritamente os builds e execute em estágios
    V. Build, Release, Run...
    VI. Processos
    Execute a aplicação como um ou mais processos que não armazenam estado
    VI. Processos...
    VII. Vínculo de porta
    Exporte serviços por ligação de porta
    VII. Vínculo de porta...
    VIII. Concorrência
    Dimensione por um modelo de processo
    VIII. Concorrência...
    IX. Descartabilidade
    Maximar a robustez com inicialização e desligamento rápido
    IX. Descartabilidade...
    X. Dev/Prod semelhantes
    Mantenha o desenvolvimento, teste, produção o mais semelhante possível
    X. Dev/Prod semelhantes...
    XI. Logs
    Trate logs como fluxo de eventos
    XI. Logs...
    XII. Processos de Admin
    Executar tarefas de administração/gerenciamento como processos pontuais
    XII. Processos de Admin...
    Text is not SVG - cannot display

  • DevOps

    DevOps é um conjunto de práticas que combina o desenvolvimento de software e as operações de TI. Seu objetivo é diminuir o ciclo de vida do desenvolvimento e prover uma entrega contínua de software com alta qualidade. DevOps se complementa com o desenvolvimento ágil.

    devops

Estilos e padrões

Voltar ao topo