loading...
Cover image for [PT-BR] Projeto e-Money: Arquitetura

[PT-BR] Projeto e-Money: Arquitetura

gmarcial profile image Guilherme Marcial Updated on ・7 min read

Aviso:

O assunto principal do artigo será a arquitetura do projeto e-Money, onde apenas conterá um resumo sobre o projeto em sí, sendo imprescindível acessar ao repositório do projeto: https://github.com/gmarcial/e-money, para conhecer a fundo sobre e não se perder durante a leitura.

Por hora o projeto só vai contar com o desenvolvimento e entrega do backend, ficando aberto a possibilidade das demais partes como clientes mobile e web.


Projeto:

O e-Money é uma solução para um problema fictício, com o objetivo de além a conclusão do meu curso, ser um laboratório de estudos para evolução profissional e portfólio do meu trabalho.

Tem como premissa ser open-source, aberto desde o início, podendo acompanhar e saber mais sobre em seu repositório no github.

O nome do projeto vem do auto intitulado valor monetário representado através de créditos eletrônicos que tem a finalidade servir de moeda apenas dentro da plataforma, onde é movimentado e utilizado para realização de pagamentos dentro da plataforma.

O e-Money em sua base é um sistema de pagamentos em comum de serviços de entidades que pertencem e participam da plataforma, tendo os usuários como consumidores, que pagam utilizando a moeda e-Money.

Para um serviço estar disponível para pagamento na plataforma, é preciso se integrar ao hub.

Ex:

Um serviço como o de transporte circular, caso seja participante da plataforma, poderá ser pago com a moeda e-Money.


O desafio

Mesmo este sendo meu primeiro artigo, tenho como objetivo o desafio de registrar o ciclo de desenvolvimento deste projeto, compartilhando não somente as soluções e resultados, mas buscando demonstrar todas as decisões tomadas durante o processo, resultando em um histórico da evolução e portfólio do meu trabalho, pois estará aberto a feedback, discussões, compartilhamentos, contribuições e tudo aquilo que venha agregar.

O ciclo é composto pelas seguintes etapas:

Design, develop, test and deploy

Começando pelo design da solução como um todo, que é a proposta deste artigo, ficando os demais registros para respectivas entregas das features, onde ficarei de decidir sua granularidade, podendo vir com um ou mais temas ao mesmo tempo.

Esse artigo tem como objetivo apresentar e explicar a arquitetura inicial projetada, onde provavelmente irá evoluir durante o caminho.

Vamos analisar a arquitetura como um todo e depois passando parte por parte até que percorremos por completo.

Para não ficar perdido em relação ao conteúdo a seguir, sugiro dar uma passado no repositorio do projeto: https://github.com/gmarcial/e-money


Arquitetura:

Alt Text

Amplie a imagem para visualizar melhor

A arquitetura por parte dos clientes, inicialmente é composta somente por primários que farão o interfaceamento com os usuários finais, tendo cada um deles uma finalidade diferente, pois cada contexto tem suas necessidades, sendo web para o back office onde os administradores irão gerenciar a plataforma, já os cidadãos, utilizam as plataformas mobile para acesso e gerenciamento de sua conta e máquinas de pagamento para pagamento dos serviços.

Com objetivo de evitar acesso direto aos recursos, principalmente a api, a frente de todas requisições terá um proxy reverso que pela sua maturidade a escolha foi o nginx. Toda comunicação passará por ele, será o filtro inicial antes do redirecionamento, realizando alguns trabalhos gerais e genéricos em relação a requisição, intermediando entre os recursos internos e os requisitantes.

Uma das partes mais importantes é a api rest utilizando em seus contratos de comunicação o formato json, responsável pela operacionalização da plataforma, aplicando as regras de negócio.
Irá servir aos clientes, estará integrado ao vault para gerenciamento dos segredos que estarão envolvidos na infra e em algumas das regras de negócio, onde iremos nos aprofundar mais a frente em próximos artigos, e o banco de dados postgres para persistências das informações, tanto para a api, quanto ao vault, podendo adotar abordagens relacional e não relacional.

O projeto tem como premissa ser cloud native, que será optado entre a google cloud e a digital ocean, tendo como restrição o custo financeiro final, por se tratar de um projeto sem fins lucrativos e financiado por fundos pessoais.

Todo o projeto por questões de segurança estaria em uma VPC e sub-redes para não estarem expostos diretamente a internet, além de ter o proxy como um gateway, criando um ambiente seguro, gerenciado em várias etapas e claro em containers docker.

Agora vamos falar detalhadamente de cada parte.


Clientes:

Alt Text

Amplie a imagem para visualizar melhor

Todos clientes primários por fim vão representar um usuário final, seja um administrador ou um cidadão.

A responsabilidade do administrador é gerenciar a plataforma, muitas das vezes tendo um terminal de trabalho onde não caberá somente a responsabilidade do gerenciamento da plataforma a e-Money, podendo também trabalhar com outras finalidades, sendo a web uma ótima plataforma para o back office.

Já para os cidadãos que utilizam a plataforma como consumidores finais, que precisam de uma maior praticidade e mobilidade para gerenciarem suas contas de qualquer lugar, a escolha são as plataformas mobile.

Por segurança a plataforma só aceita clientes primários, os quais confiá, sendo autenticados e autorizados para interagir com os serviços, passando pelo processo de MTLS, além do tunelamento seguro para comunicação.

Além da parte do cliente, outro nível de segurança é por parte do usuário final que o utiliza, precisando também se autenticar, para sua identificação durante o ciclo de uso e autorização das ações dentro da plataforma, utilizando tokens de identidade(id token) e acesso(access token).

Quando existir situações sem autenticação do usuário final, MTLS será o suficiente.


Cliente de pagamento:

Alt Text

Amplie a imagem para visualizar melhor

O cliente especifico para pagamentos é por onde as entidades parceiras utilizaram para realizar as transações referente ao pagamento dos serviços consumidos e somente por eles que os mesmos ocorreram.

Além de se autenticar e ocorrer a tunelização da comunicação com MTLS, esse tipo de cliente em especial, irá representar uma entidade da qual efetuará as transações através dele, sua identidade tem que corresponder a da qual foi configurado e certificado.

Somente será autorizado transações quando autenticado e corresponder a entidade para qual foi configurada, logo sua identidade é previamente feita e ligada a sua configuração na plataforma pela administração.


Proxy reverso:

Alt Text

Amplie a imagem para visualizar melhor

O proxy intermedia a comunicação, é quem conhece e redireciona para os responsáveis por lidar com as requisições, podendo aplicar alguma medida manipulando a requisição, segurança, balanceamento e filtro, como só aceitar clientes válidos e confiáveis antes de redirecionar, pois é o primeiro a receber a requisição.

Isolando os recursos do mundo externo, ele é único conhecido e está a frente de toda comunicação, mantendo os demais seguros.

Além de segurança, ele pode contribuir para performance e outras medidas, como cache, filtros e etc. Todos as requisições são intermediadas por ele, podendo fazer a manipulação e ações na entrada e saída, conforme as possibilidades de configuração do nginx.

Outra solução que poderia se encaixar muito bem seria um api gateway, sendo alguns baseados propriamente em cima do nginx.


Contrato com a api:

O consumo da api deve ser claro, tento bem modelado os recursos, expressando seus contratos e principalmente expor o estado, resultado de cada ação e operação, para que diante disso o consumidor possa ficar ciente e a partir disso possivelmente realizar os comportamentos corretos conforme a situação.

Para isso a api deve estar bem documentada, deixando explícito seus recursos, ações, e como realizar e seus comportamentos esperados, além disso um contrato em comum das respostas, seus estados e regras conforme as situações.

Base:

  • Status code
  • Estado da ação
  • Descrição
  • Resultado

Ex:

Casos 2xx:

Status code: 201
{
  "state": "success",
  "description": "A conta foi aberta com sucesso",
  "result": {
    "resource": "accounts/8129391"
  }
}

Casos 4xx:

Status code: 400
{
  "state": "Dados invalidos",
  "description": "A conta não pode ser aberta, ",
  "result": {
    "messages": [
        {
          "property":"...",
          "value":"..."
        },
        {
          "property":"...",
          "value":[
              {
                "property":"...",
                "value":"..."
              },
              {
                "property":"...",
                "value":"..."
              },
              {
                "property":"...",
                "value":"..."
              }
            ]
        },
        {
          "property":"...",
          "value":"..."
        }
      ]
  }
}

Casos 5xx:

Status code: 500
{
  "state": "Erro inesperado",
  "description": "Ocorreu um erro interno ao tentar processar esta ação"
}

Persistencia dos dados:

Alt Text

Amplie a imagem para visualizar melhor

O RDBMS escolhido será o postgresql, além da sua maturidade, popularidade, eficiência e extensibilidade, aproveitar tanto da sua abordagem relacional, quanto a não relacional com a feature de persistências de arquivos json e jsonb, podendo obter também uma abordagem de documentos.

Toda comunicação com o banco será segura através de conexões utilizando TLS.

Estando em avaliação referente a restrição financeira se será optado por uma abordagem de um serviço gerenciado nas clouds propostas, ou não.


Vault:

Alt Text

Amplie a imagem para visualizar melhor

A aplicação lidará e gerenciará segredos, seja por parte da infraestrutura quanto de algumas regras de negócio, além de armazenar, também gerar.

Não somente os segredos, mas lidar corretamente com criptografia que terá uma grande atuação no projeto.

Para que não precise implementar na mão ou utilizar soluções não tão confiáveis, o vault vem como solução especializada e madura nisso, sendo utilizado como um serviço integrado ao projeto e o melhor, aplicando esses conceitos críticos de forma correta, além de abrir outras possibilidades, pois o mesmo tem mais features do que está descrito aqui e de uma forma mais aprofundada.

A persistência das informações ocorrerá a partir da utilização de um banco postgres próprio e isolado.


Considerações finais

Agradeço por todos que leram até o final, é um passo importante para mim estar escrevendo meu primeiro artigo e estar compartilhando minha experiência nesse projeto.

Provavelmente nos próximos capítulos já será sobre a primeira entrega, dando início ao desenvolvimento.

Novamente, estou aberto a feedbacks, discussões, trocar uma ideia, compartilhar, contribuições e tudo aquilo que venha agregar e contribuir para a evolução contínua.

Obrigado.

Discussion

pic
Editor guide