Publicado enAI AI Chatbot C4 Model

Estudio de caso del modelo C4: Sistema de banca por internet de Big Bank plc

1. Resumen ejecutivo

Este estudio de caso documenta la arquitectura del Sistema de banca por internet para Big Bank plc. El sistema está diseñado para permitir a los clientes de banca personal ver sus saldos de cuenta, consultar el historial de transacciones y realizar pagos a través de navegadores web y dispositivos móviles.

La arquitectura sigue el modelo C4 (Contexto, Contenedores, Componentes, Código), proporcionando una vista jerárquica del sistema desde abstracciones de alto nivel hasta la infraestructura de despliegue.

2. Nivel 1: Diagrama de contexto del sistema

Objetivo: Mostrar el sistema en el contexto de sus usuarios y dependencias externas.

Diagrama de referencia: Imagen 4 (principal) e Imagen 1 (vista simplificada).

Análisis

El Sistema de banca por internet se encuentra dentro del límite de la Big Bank plc empresa. Actúa como un canal digital para el cliente de banca personal.

C4 Model System Context Diagram for Internet Banking System

  • Usuarios (actores):

    • Cliente de banca personal: El usuario principal que interactúa con el sistema para ver saldos y realizar pagos.

    • Personal de servicio al cliente: Empleados del banco que ayudan a los clientes (mostrados en la imagen 4).

    • Personal de oficina trasera: Personal de administración y soporte (mostrado en la imagen 4).

  • Sistemas externos:

    • Sistema de banca en mainframe: El sistema de registro. Almacena toda la información básica de banca (clientes, cuentas, transacciones). El sistema de banca en línea depende de este para obtener datos autoritativos.

    • Sistema de correo electrónico: El sistema interno de Microsoft Exchange utilizado para enviar notificaciones (por ejemplo, restablecimiento de contraseñas, confirmaciones) a los clientes.

    • ATM: Un sistema de software independiente que permite retiros en efectivo (mostrado en la Imagen 4 para demostrar el ecosistema más amplio).

Relación clave: El cliente interactúa con el sistema de banca en línea, que a su vez actúa como una fachada del sistema heredado de mainframe para recuperar datos y procesar pagos.

3. Nivel 2: Diagrama de contenedores

Objetivo: Mostrar las elecciones tecnológicas de alto nivel y cómo se distribuyen las responsabilidades a través del sistema.

Diagrama de referencia: Imagen 2.

Análisis

El «sistema de banca en línea» del Nivel 1 se descompone en cinco contenedores distintos (unidades desplegables).

C4 Model Container Diagram for Internet Banking System

  1. Aplicación web (Java y Spring MVC):

    • Rol: Sirve como punto de entrada para los usuarios web.

    • Función: Entrega contenido estático (HTML/CSS/JS) y la aplicación de página única (SPA) al navegador del cliente a través de HTTPS.

  2. Aplicación de página única (JavaScript y Angular):

    • Rol: La lógica del lado del cliente que se ejecuta en el navegador.

    • Función: Proporciona todo el conjunto de funcionalidades de banca en línea. Realiza llamadas a la API al backend.

  3. Aplicación móvil (Xamarin):

    • Rol: La aplicación del lado del cliente para dispositivos móviles.

    • Función:Proporciona un subconjunto limitado de funcionalidades en comparación con la aplicación web. También realiza llamadas a la API al backend.

  4. Aplicación de la API (Java y Spring MVC):

    • Rol:La lógica central del backend.

    • Función:Exponer una API de JSON/HTTPS. Maneja la autenticación, la lógica de negocio y la comunicación con sistemas externos (Base de datos, Mainframe, Correo electrónico).

  5. Base de datos (Esquema de Oracle Database):

    • Rol:Persistencia de datos.

    • Función:Almacena la información de registro de usuarios, credenciales encriptadas y registros de acceso.Nota: Los datos centrales de banca permanecen en el Mainframe.

Relación clave:Tanto la aplicación web (a través de la SPA) como la aplicación móvil se comunican con laAplicación de la API. La aplicación de la API luego se comunica con laBase de datospara datos locales y con elMainframepara los datos centrales de banca.

4. Nivel 3: Diagrama de componentes

Objetivo:Aumentar el zoom en un contenedor específico (la Aplicación de la API) para mostrar sus bloques de construcción internos.

Diagrama de referencia:Imagen 3.

Análisis

Este diagrama descompone elAplicación de la APIcontenedor en componentes lógicos.

C4 Model Component Diagram for Internet Banking System

  • Controladores (Controladores Rest de Spring MVC): Estos manejan las solicitudes HTTP entrantes.

    • Controlador de Inicio de Sesión: Maneja la autenticación de usuarios.

    • Controlador de Restablecimiento de Contraseña: Maneja los flujos de recuperación de contraseñas.

    • Controlador de Resumen de Cuentas: Recupera los datos de la cuenta para el usuario.

  • Componentes (Spring Beans): Estos contienen la lógica de negocio.

    • Componente de Seguridad: Maneja el inicio de sesión y el cambio de contraseñas. Utilizado por los controladores de Inicio de Sesión y Restablecimiento de Contraseña.

    • Componente de Correo Electrónico: Maneja el envío de correos electrónicos. Utilizado por el controlador de Restablecimiento de Contraseña.

    • Fachada del Sistema Bancario Mainframe: Un envoltorio alrededor del sistema externo Mainframe. Traduce las llamadas de API internas al formato XML/HTTPS requerido por el Mainframe heredado. Utilizado por el Controlador de Resumen de Cuentas.

Relación Clave: El Controlador de Resumen de Cuentas utiliza el Fachada del Sistema Bancario Mainframe para obtener datos del Mainframe externo, demostrando la separación de responsabilidades entre la capa de API y la capa de integración.

5. Nivel 4: Diagrama de Despliegue

Objetivo: Mostrar cómo los contenedores de software se asignan a la infraestructura física.

Diagrama de Referencia: Imagen 5.

Análisis

Este diagrama ilustra el entorno de tiempo de ejecución.

C4 Model Deployment Diagram for Internet Banking System

  • Lado del Cliente:

    • Dispositivo Móvil:Ejecuta la aplicación móvil (iOS/Android).

    • Computadora:Ejecuta el navegador web (Chrome/Firefox/Safari/Edge) que aloja la aplicación de página única.

  • Centro de datos de Big Bank plc:

    • Servidores web (bigbank-web*):** Nodos Ubuntu 16.04 LTS en ejecuciónApache Tomcat 8.x.

      • Aloja elAplicación webyAplicación de API.

    • Servidores de base de datos (bigbank-db01/02):Nodos Ubuntu 16.04 LTS en ejecuciónOracle 12c.

      • Oracle – Primario:La base de datos principal.

      • Oracle – Secundario:Una réplica para redundancia/alta disponibilidad.

Relación clave:La aplicación móvil y el navegador web se conectan a través de internet alAplicación de APIalojada en Tomcat. La aplicación de API se conecta mediante JDBC al clúster de base de datos Oracle.

6. Conceptos y directrices clave aplicadas

Basado en este estudio de caso, se aplicaron los siguientes principios de modelado C4:

  1. Niveles de abstracción:El modelo pasa con éxito de ‘¿Quién lo utiliza?’ (Contexto) a ‘¿De qué está hecho?’ (Contenedores) a ‘¿Cómo está organizado?’ (Componentes) a ‘¿Dónde se ejecuta?’ (Despliegue).

  2. Límites de alcance:

    • En el Nivel 1, el límite de «Big Bank plc» distingue claramente los sistemas internos de los actores externos.

    • En el Nivel 2, el límite del «Sistema de Banca en Línea» encapsula el software específico que se está construyendo, separándolo del Mainframe heredado.

  3. Separación de preocupaciones:

    • Frontend frente a Backend:La separación de la Aplicación de página única (frontend) de la Aplicación de API (backend) permite el desarrollo y escalado independientes.

    • Separación de datos:Los datos sensibles de banca central se mantienen en el Mainframe, mientras que el Sistema de Banca en Línea solo almacena en caché los datos de acceso del usuario necesarios en su propia base de datos Oracle.

  4. Neutralidad tecnológica (cuando sea apropiado):Los diagramas especifican tecnologías (Java, Angular, Oracle) cuando son relevantes para la decisión arquitectónica, pero se centran principalmente en las relacionesy responsabilidadesde los bloques.

  5. Notación:Se utiliza la notación estándar C4:

    • Persona:Figuras de palo (o círculos en este estilo específico de representación).

    • Sistema de software/Contenedor/Componente:Rectángulos redondeados con colores distintos (Azul para interno/primario, Gris para externo/secundario).

    • Relaciones:Flechas punteadas con etiquetas que describen el protocolo (por ejemplo, [HTTPS], [JSON], [JDBC]).