Исследование по модели C4: Интернет-банкинговая система Big Bank plc

1. Краткое резюме

В этом исследовании описывается архитектура системыИнтернет-банкинговой системыдляBig Bank plc. Система разработана для того, чтобы личные клиенты банков могли просматривать балансы своих счетов, просматривать историю транзакций и совершать платежи через веб-браузеры и мобильные устройства.

Архитектура следует моделимодели C4 (Контекст, контейнеры, компоненты, код), обеспечивая иерархический взгляд на систему от высоких абстракций до инфраструктуры развертывания.


2. Уровень 1: Диаграмма контекста системы

Цель: Показать систему в контексте её пользователей и внешних зависимостей.

Ссылочная диаграмма: Изображение 4 (основное) и Изображение 1 (упрощённый вид).

Анализ

СистемаИнтернет-банкинговой системы находится в пределах границBig Bank plc корпорации. Она выступает в качестве цифрового канала дляличных клиентов банков.

C4 Model System Context Diagram for Internet Banking System

  • Пользователи (акторы):

    • Личный клиент банка: Основной пользователь, который взаимодействует с системой для просмотра балансов и совершения платежей.

    • Персонал службы поддержки клиентов: Сотрудники банка, которые помогают клиентам (показаны на Изображении 4).

    • Персонал офиса поддержки: Административный и вспомогательный персонал (показаны на Изображении 4).

  • Внешние системы:

    • Основная банковская система (mainframe): Система хранения данных. Хранит всю основную банковскую информацию (клиенты, счета, транзакции). Интернет-банкинг зависит от нее для получения авторитетных данных.

    • Система электронной почты: Внутренняя система Microsoft Exchange, используемая для отправки уведомлений (например, сброс пароля, подтверждения) клиентам.

    • Банкомат: Отдельная программная система, позволяющая снимать наличные (показана на рисунке 4, чтобы продемонстрировать более широкую экосистему).

Ключевое взаимодействие: Клиент взаимодействует с системой интернет-банкинга, которая, в свою очередь, выступает в роли фасада для унаследованной основной системы (mainframe) для получения данных и обработки платежей.


3. Уровень 2: Диаграмма контейнеров

Цель: Показать высокий уровень выбора технологий и распределение ответственности по всей системе.

Справочная диаграмма: Рисунок 2.

Анализ

Система интернет-банкинга с уровня 1 распадается на пять различных контейнеров (развертываемых единиц).

C4 Model Container Diagram for Internet Banking System

  1. Веб-приложение (Java и Spring MVC):

    • Роль: Выступает точкой входа для веб-пользователей.

    • Функция: Доставляет статическое содержимое (HTML/CSS/JS) и одностраничное приложение (SPA) в браузер клиента через HTTPS.

  2. Одностраничное приложение (JavaScript и Angular):

    • Роль: Логика на стороне клиента, выполняемая в браузере.

    • Функция: Обеспечивает полный набор функций интернет-банкинга. Выполняет вызовы API к серверной части.

  3. Мобильное приложение (Xamarin):

    • Роль: Приложение на стороне клиента для мобильных устройств.

    • Функция:Предоставляет ограниченный набор функций по сравнению с веб-приложением. Также выполняет вызовы API к бэкенду.

  4. Приложение API (Java и Spring MVC):

    • Роль: Основная логика бэкенда.

    • Функция: Предоставляет API в формате JSON/HTTPS. Обрабатывает аутентификацию, бизнес-логику и взаимодействие с внешними системами (База данных, Мэйнфрейм, Электронная почта).

  5. База данных (схема Oracle):

    • Роль: Хранение данных.

    • Функция: Хранит информацию о регистрации пользователя, хэшированные учетные данные и журналы доступа.Примечание: Основные банковские данные остаются в Мэйнфрейме.

Ключевое отношение: Как веб-приложение (через SPA), так и мобильное приложение взаимодействуют сПриложения API. Затем приложение API взаимодействует сБазой данных для локальных данных и сМэйнфреймом для основных банковских данных.


4. Уровень 3: Диаграмма компонентов

Цель: Показать внутренние элементы конкретного контейнера (приложения API).

Справочная диаграмма: Рисунок 3.

Анализ

На этой диаграмме показано разбиениеПриложения API на логические компоненты.

C4 Model Component Diagram for Internet Banking System

  • Контроллеры (Spring MVC Rest-контроллеры): Они обрабатывают входящие HTTP-запросы.

    • Контроллер входа: Обрабатывает аутентификацию пользователей.

    • Контроллер сброса пароля: Обрабатывает процессы восстановления пароля.

    • Контроллер сводки счетов: Получает данные счетов для пользователя.

  • Компоненты (Spring Beans): Они содержат бизнес-логику.

    • Компонент безопасности: Обрабатывает вход в систему и смену паролей. Используется контроллерами входа и сброса пароля.

    • Компонент электронной почты: Обрабатывает отправку электронной почты. Используется контроллером сброса пароля.

    • Фасад банковской системы мейнфрейма: Оболочка вокруг внешней системы мейнфрейма. Преобразует внутренние вызовы API в формат XML/HTTPS, требуемый устаревшей системой мейнфрейма. Используется контроллером сводки счетов.

Ключевое отношение: Контроллер Сводка счетов использует Фасад банковской системы мейнфрейма для получения данных из внешнего мейнфрейма, демонстрируя разделение ответственности между слоем API и слоем интеграции.


5. Уровень 4: Диаграмма развертывания

Цель: Показать, как программные контейнеры соответствуют физической инфраструктуре.

Справочная диаграмма: Рисунок 5.

Анализ

Эта диаграмма иллюстрирует среду выполнения.

C4 Model Deployment Diagram for Internet Banking System

  • Сторона клиента:

    • Мобильное устройство: Запускает мобильное приложение (iOS/Android).

    • Компьютер: Запускает веб-браузер (Chrome/Firefox/Safari/Edge), который запускает одностраничное приложение.

  • Центр обработки данных Big Bank plc:

    • Веб-серверы (bigbank-web*):** Узлы Ubuntu 16.04 LTS, запускающиеApache Tomcat 8.x.

      • ХоститВеб-приложение и Приложению API.

    • Серверы баз данных (bigbank-db01/02): Узлы Ubuntu 16.04 LTS, запускающиеOracle 12c.

      • Oracle – основной: Основная база данных.

      • Oracle – резервный: Реплика для обеспечения отказоустойчивости/высокой доступности.

Ключевое отношение: Мобильное приложение и веб-браузер подключаются через интернет к Приложению API размещённому на Tomcat. Приложение API подключается через JDBC к кластеру баз данных Oracle.


6. Основные концепции и принципы, применённые

На основе этого кейса были применены следующие принципы моделирования C4:

  1. Уровни абстракции: Модель успешно переходит от «Кто им пользуется?» (Контекст) к «Из чего оно состоит?» (Контейнеры), затем к «Как организовано?» (Компоненты) и далее к «Где оно работает?» (Развертывание).

  2. Границы охвата:

    • На уровне 1 граница «Big Bank plc» четко разделяет внутренние системы и внешние субъекты.

    • На уровне 2 граница «Система интернет-банкинга» инкапсулирует конкретный разрабатываемый программный продукт, отделяя его от унаследованной основной машины.

  3. Разделение ответственности:

    • Фронтенд против бэкенда:Разделение одностраничного приложения (фронтенд) от приложения API (бэкенд) позволяет независимо разрабатывать и масштабировать.

    • Разделение данных:Чувствительные данные основного банковского приложения хранятся в основной машине, в то время как система интернет-банкинга кэширует только необходимые данные доступа пользователей в собственной базе данных Oracle.

  4. Технологическая нейтральность (где уместно):На диаграммах указываются технологии (Java, Angular, Oracle), когда они важны для архитектурного решения, но в основном акцент делается на отношениях и ответственности блоков.

  5. Нотация: Используется стандартная нотация C4:

    • Человек: Миниатюрные фигуры (или круги в данном конкретном стиле изображения).

    • Программная система/контейнер/компонент: Округлые прямоугольники с различными цветами (синий для внутренних/основных, серый для внешних/второстепенных).

    • Отношения: Штриховые стрелки с метками, описывающими протокол (например, [HTTPS], [JSON], [JDBC]).