Estudo de Caso do Modelo C4: Sistema de Banco na Internet da Big Bank plc - Go 2 Posts Portuguese

1. Resumo Executivo

Este estudo de caso documenta a arquitetura do Sistema de Banco na Internet para Big Bank plc. O sistema foi projetado para permitir que clientes de banco pessoal visualizem seus saldos de conta, visualizem o histórico de transações e efetuem pagamentos por meio de navegadores da web e dispositivos móveis.

A arquitetura segue o Modelo C4 (Contexto, Contêineres, Componentes, Código), fornecendo uma visão hierárquica do sistema desde abstrações de alto nível até a infraestrutura de implantação.

2. Nível 1: Diagrama de Contexto do Sistema

Objetivo: Mostrar o sistema no contexto de seus usuários e dependências externas.

Diagrama de Referência: Imagem 4 (Principal) e Imagem 1 (Visualização Simplificada).

Análise

O Sistema de Banco na Internet está dentro da fronteira da Big Bank plc empresa. Atua como um canal digital para o Cliente de Banco Pessoal.

C4 Model System Context Diagram for Internet Banking System

Usuários (Atores):
- Cliente de Banco Pessoal: O usuário principal que interage com o sistema para visualizar saldos e efetuar pagamentos.
- Equipe de Atendimento ao Cliente: Funcionários do banco que auxiliam os clientes (mostrados na Imagem 4).
- Equipe de Back Office: Pessoal de administração e suporte (mostrado na Imagem 4).
Sistemas Externos:
- Sistema de Banco Mainframe: O sistema de registro. Armazena todas as informações centrais de banco (clientes, contas, transações). O Sistema de Banco na Internet depende deste para dados autoritativos.
- Sistema de E-mail: O sistema interno do Microsoft Exchange usado para enviar notificações (por exemplo, redefinições de senha, confirmações) aos clientes.
- Caixa Eletrônico (ATM): Um sistema de software separado que permite saques em dinheiro (mostrado na Imagem 4 para demonstrar o ecossistema mais amplo).

Relação Principal: O cliente interage com o Sistema de Banco na Internet, que por sua vez atua como uma fachada para o sistema legado Mainframe para recuperar dados e processar pagamentos.

3. Nível 2: Diagrama de Container

Objetivo: Mostrar as escolhas de tecnologia de alto nível e como as responsabilidades são distribuídas ao longo do sistema.

Diagrama de Referência: Imagem 2.

Análise

O ‘Sistema de Banco na Internet’ do Nível 1 é decomposto em cinco contêineres distintos (unidades implantáveis).

C4 Model Container Diagram for Internet Banking System

Aplicativo Web (Java e Spring MVC):
- Função: Serve como ponto de entrada para usuários da web.
- Função: Entrega conteúdo estático (HTML/CSS/JS) e o Aplicativo de Página Única (SPA) ao navegador do cliente por meio de HTTPS.
Aplicativo de Página Única (JavaScript e Angular):
- Função: A lógica do lado do cliente em execução no navegador.
- Função: Fornece todo o conjunto de funcionalidades de banco na internet. Faz chamadas de API para o backend.
Aplicativo Móvel (Xamarin):
- Função: O aplicativo do lado do cliente para dispositivos móveis.
- Função:Fornece um subconjunto limitado de funcionalidades em comparação com o aplicativo da web. Também realiza chamadas à API para o backend.
Aplicativo da API (Java e Spring MVC):
- Função:A lógica central do backend.
- Função:Exibe uma API JSON/HTTPS. Ela gerencia autenticação, lógica de negócios e comunicação com sistemas externos (Banco de Dados, Mainframe, E-mail).
Banco de Dados (Esquema do Oracle Database):
- Função:Persistência de dados.
- Função:Armazena informações de registro de usuário, credenciais criptografadas e registros de acesso.Observação: Os dados principais de banco permanecem no Mainframe.

Relacionamento Chave:Tanto o Aplicativo Web (via o SPA) quanto o Aplicativo Móvel se comunicam com oAplicativo da API. O Aplicativo da API então se comunica com oBanco de Dadospara dados locais e com oMainframepara dados principais de banco.

4. Nível 3: Diagrama de Componentes

Objetivo:Aumentar o foco em um contêiner específico (o Aplicativo da API) para mostrar seus blocos de construção internos.

Diagrama de Referência:Imagem 3.

Análise

Este diagrama divide oAplicativo da APIem componentes lógicos.

C4 Model Component Diagram for Internet Banking System

Controladores (Controladores Rest do Spring MVC): Esses manipulam as requisições HTTP recebidas.
- Controlador de Entrada: Manipula a autenticação do usuário.
- Controlador de Redefinição de Senha: Manipula os fluxos de recuperação de senha.
- Controlador de Resumo de Contas: Recupera os dados da conta do usuário.
Componentes (Spring Beans): Esses contêm a lógica de negócios.
- Componente de Segurança: Manipula o acesso e a alteração de senhas. Utilizado pelos controladores de Entrada e de Redefinição de Senha.
- Componente de E-mail: Manipula o envio de e-mails. Utilizado pelo controlador de Redefinição de Senha.
- Facade do Sistema Bancário Mainframe: Um invólucro ao redor do sistema Mainframe externo. Traduz as chamadas de API internas para o formato XML/HTTPS exigido pelo Mainframe legado. Utilizado pelo Controlador de Resumo de Contas.

Relação Chave: O Controlador de Resumo de Contas usa o Facade do Sistema Bancário Mainframe para obter dados do Mainframe externo, demonstrando a separação de responsabilidades entre a camada de API e a camada de integração.

5. Nível 4: Diagrama de Implantação

Objetivo: Mostrar como os contêineres de software se mapeiam para a infraestrutura física.

Diagrama de Referência: Imagem 5.

Análise

Este diagrama ilustra o ambiente de execução.

C4 Model Deployment Diagram for Internet Banking System

Lado do Cliente:
- Dispositivo Móvel:Executa o aplicativo móvel (iOS/Android).
- Computador:Executa o navegador da web (Chrome/Firefox/Safari/Edge) que hospeda o aplicativo de página única.
Centro de dados da Big Bank plc:
- Servidores web (bigbank-web*):** Nós Ubuntu 16.04 LTS em execução Apache Tomcat 8.x.
  - Hospeda o Aplicativo web e Aplicativo da API.
- Servidores de banco de dados (bigbank-db01/02): Nós Ubuntu 16.04 LTS em execução Oracle 12c.
  - Oracle – Primário: O banco de dados principal.
  - Oracle – Secundário: Uma réplica para redundância/alta disponibilidade.

Relação principal: O aplicativo móvel e o navegador da web se conectam pela internet ao Aplicativo da API hospedado no Tomcat. O aplicativo da API se conecta via JDBC ao cluster do banco de dados Oracle.

6. Conceitos e diretrizes principais aplicados

Com base neste estudo de caso, foram aplicados os seguintes princípios de modelagem C4:

Níveis de abstração: O modelo passa com sucesso de “Quem o usa?” (Contexto) para “O que é feito?” (Contêineres) para “Como é organizado?” (Componentes) para “Onde é executado?” (Implantação).
Limites de escopo:
- No Nível 1, a fronteira da “Big Bank plc” distingue claramente os sistemas internos dos atores externos.
- No Nível 2, a fronteira do “Sistema de Banco na Internet” encapsula o software específico que está sendo desenvolvido, separando-o do Mainframe legado.
Separação de Responsabilidades:
- Frontend vs. Backend:A separação da Aplicação de Página Única (frontend) da Aplicação de API (backend) permite o desenvolvimento e dimensionamento independentes.
- Separação de Dados:Os dados sensíveis de banco central são mantidos no Mainframe, enquanto o Sistema de Banco na Internet apenas armazena em cache os dados de acesso do usuário necessários em seu próprio banco de dados Oracle.
Neutralidade de Tecnologia (quando apropriado):Os diagramas especificam tecnologias (Java, Angular, Oracle) quando relevantes para a decisão arquitetônica, mas focam principalmente nas relaçõese responsabilidadesdos blocos.
Notação:É utilizada a notação padrão C4:
- Pessoa:Figuras de palito (ou círculos neste estilo específico de representação).
- Sistema de Software/Container/Componente:Retângulos arredondados com cores distintas (Azul para interno/primário, Cinza para externo/secundário).
- Relações:Setas tracejadas com rótulos que descrevem o protocolo (por exemplo, [HTTPS], [JSON], [JDBC]).