はじめに
1. 概要
本事例研究では、架空の金融機関『BigBank』のインターネットバンキングシステムのアーキテクチャ設計を分析しています。プロジェクトの目的は、既存のレガシーコアバンキングインフラと統合しながら、個人向けバンキング顧客がウェブおよびモバイル経由で安全かつアクセスしやすく、複数チャネルで口座にアクセスできるようにすることです。
このアーキテクチャは、C4モデル(コンテナ図)を使用して文書化されており、システムのコンテナ(アプリケーション、データベースなど)がどのように相互に作用するか、および高レベルの技術選定を可視化しています。

2. ビジネス上の課題
-
レガシーシステムとの統合:銀行は顧客データの根幹を担う強力だが古くなった「メインフレームバンキングシステム」を保有しています。新しいシステムは、メインフレームを即座に置き換えることなく、このデータを公開する必要がありました。
-
複数チャネルへのアクセス:顧客はデスクトップブラウザとモバイルデバイスの両方からアクセスすることを要求しました。
-
セキュリティ:機密性の高い金融データを扱うには、厳格な認証と安全な通信チャネルが必要です。
3. アーキテクチャ的解決策(C4コンテナビュー)
この解決策は、プレゼンテーション層がビジネスロジック層およびデータ層から分離された、非結合型のシステムとして設計されています。
A. ユーザーインターフェース層(フロントエンド)
このシステムは、個人向けバンキング顧客:
-
シングルページアプリケーション(SPA):
-
技術:JavaScript および Angular。
-
役割: これは顧客のウェブブラウザで実行されます。これにより、インターネットバンキング機能の全範囲が提供されます。全範囲の インターネットバンキング機能の全範囲。動的で応答性の高いインターフェースであり、バックエンドと非同期で通信します。
-
-
ウェブアプリケーション:
-
技術: Java および Spring MVC。
-
役割: これはウェブ体験のエントリーポイントとして機能します。静的コンテンツ(HTML/CSS/JS)を配信し、シングルページアプリケーションをホスティングします。Angularアプリの「ランチャ」として機能します。
-
-
モバイルアプリ:
-
技術: Xamarin(クロスプラットフォーム開発を可能にするもので、おそらくiOSおよびAndroid用)。
-
役割: モバイルデバイスに最適化された「限定された機能セット」を提供します。これにより、国際送金の設定など複雑なタスクは、フルウェブ/SPAインターフェースに限定される可能性があり、バランス照会などの一般的なタスクはモバイルでも利用可能であることが示唆されます。
-
B. ビジネスロジック層(バックエンド)
-
APIアプリケーション:
-
技術: Java および Spring MVC。
-
役割: これはアーキテクチャの中枢神経系です。APIゲートウェイまたはAPIゲートウェイ またはバックエンド・フォー・フロント(BFF).
-
機能: これはウェブおよびモバイルクライアントにJSON/HTTPS API を公開します。認証、承認、およびデータリクエストのオーケストレーションを処理します。
-
C. データおよび統合層
-
データベース:
-
技術: Oracleデータベーススキーマ。
-
役割: インターネットバンキング専用のデータを格納する。ユーザー登録情報などが含まれる。ハッシュ化された認証資格情報 (セキュリティのベストプラクティス)、アクセスログを格納する。実際の預金残高は格納しない(それはメインフレームに存在する)。しない 実際の預金残高を格納する(それらはメインフレームに存在する)。
-
通信: APIアプリケーションはこのデータベースに対して、JDBC.
-
-
メインフレームバンキングシステム:
-
役割: レコードの基準となるシステム。顧客、口座、取引などの核心的なバンキング情報を格納する。
-
通信: APIアプリケーションは、HTTPS上のXML。これはメインフレームがおそらくレガシーソープベースのサービス、または構造化されたXMLデータ交換を必要とする古いシステムであることを示している。
-
-
メールシステム:
-
技術: Microsoft Exchange。
-
役割: 通知を処理する。
-
通信: APIアプリケーションはSMTP を介してExchangeサーバーにメールを送信し、その後顧客に配信する。
-
4. 主要なデータフローとユーザーの旅路
シナリオ1:Webブラウザ経由でのログイン
-
The 個人向けバンキング顧客 にアクセスする
bigbank.com/ibHTTPSを使用して。 -
リクエストは に到達するWebアプリケーション (Java/Spring MVC)。
-
Webアプリケーションは を配信するシングルページアプリケーション (Angular) を顧客のブラウザに配信する。
-
顧客はSPAで資格情報を入力する。
-
SPAはAPI呼び出しを行う(
JSON/HTTPS)を に送信するAPIアプリケーション. -
APIアプリケーションは資格情報を に対して検証するデータベース (JDBC経由)。
-
成功すると、SPAは口座残高を要求する。APIアプリケーションはこのデータを から取得するメインフレームバンキングシステム (
XML/HTTPS)を取得し、SPAに返す。
シナリオ2:モバイル取引通知
-
顧客は を介して支払いを行うモバイルアプリ (Xamarin)。
-
アプリは、次のものにリクエストを送信します。APIアプリケーション.
-
APIアプリケーションは、次のものと連携して支払いを処理します。メインフレーム.
-
APIアプリケーションは、次のものにSMTPリクエストを送信することで確認メールを発行します。メールシステム(Exchange)。
-
顧客はメール通知を受け取ります。
5. 技術的ハイライトおよびベストプラクティス
-
責任の分離:図は、「インターネットバンキング」固有のデータ(Oracle DB)と「コアバンキング」データ(メインフレーム)を明確に分離しています。これにより、ウェブレイヤーがコア財務台帳に直接アクセスすることを防ぎます。
-
プロトコル翻訳:APIアプリケーションは翻訳者として機能します。現代のフロントエンドはJSONを話しますが、レガシーなバックエンドはXMLを話します。APIアプリケーションがこのギャップを埋めます。
-
セキュリティ:資格情報はデータベースに「ハッシュ化」された形で保存され、データベースが侵害されてもプレーンテキストのパスワードが露出しないことを保証します。すべての外部通信にはHTTPS.
-
スケーラビリティ:シングルページアプリケーション(Angular)と分離されたAPIを使用することで、フロントエンドはバックエンドのロジックとは独立してスケーリングできます。













