1. 概要
このケーススタディは、インターネットバンキングシステムのビッグバンク plc。このシステムは、個人向け銀行顧客がウェブブラウザやモバイルデバイスを通じて口座残高を確認し、取引履歴を閲覧し、支払いを行うことを可能にするように設計されています。
このアーキテクチャは、C4モデル（コンテキスト、コンテナ、コンポーネント、コード）に従っており、高レベルの抽象からデプロイインフラストラクチャまで、システムの階層的な視点を提供しています。
2. レベル1：システムコンテキスト図
目的：ユーザーおよび外部依存関係の文脈の中でシステムを示す。
参照図：画像4（主な図）および画像1（簡略化されたビュー）。
分析
このインターネットバンキングシステムは、ビッグバンク plc企業の境界内に位置しています。これは、個人向け銀行顧客.
-
ユーザー（エイクター）：
-
個人向け銀行顧客：システムとやり取りして残高を確認し、支払いを行う主なユーザー。
-
カスタマーサービス担当者：顧客を支援する銀行の従業員（画像4に示す）。
-
バックオフィス担当者：管理およびサポート担当者（画像4に示す）。
-
-
外部システム:
-
メインフレーム銀行システム: 記録の基準となるシステム。すべての核心的な銀行情報（顧客、口座、取引）を格納する。インターネットバンキングシステムは、このシステムを信頼できるデータの源として依存している。
-
メールシステム: 顧客に通知（例：パスワードリセット、確認）を送信するために使用する内部のMicrosoft Exchangeシステム。
-
ATM: 現金引き出しを可能にする別々のソフトウェアシステム（広範なエコシステムを示すために画像4に表示）。
-
重要な関係: 顧客はインターネットバンキングシステムとやり取りし、そのシステムはレガシーなメインフレームシステムへのフェイサードとして機能し、データの取得や支払い処理を行う。
3. レベル2：コンテナ図
目的: 高レベルの技術選定と、システム全体にわたる責任の分配を示す。
参考図: 画像2。
分析
レベル1の「インターネットバンキングシステム」は、5つの異なるコンテナ（デプロイ可能な単位）に分解される。
-
Webアプリケーション（JavaおよびSpring MVC）:
-
役割: Webユーザーのエントリーポイントとして機能する。
-
機能: HTTPS経由で静的コンテンツ（HTML/CSS/JS）およびシングルページアプリケーション（SPA）を顧客のブラウザに配信する。
-
-
シングルページアプリケーション（JavaScriptおよびAngular）:
-
役割: ブラウザで実行されるクライアント側のロジック。
-
機能: インターネットバンキングのすべての機能を提供する。バックエンドに対してAPI呼び出しを行う。
-
-
モバイルアプリ（Xamarin）:
-
役割: モバイルデバイス用のクライアント側アプリケーション。
-
機能:Webアプリと比較して、限定的な機能しか提供しません。また、バックエンドへのAPI呼び出しも行います。
-
-
APIアプリケーション（JavaおよびSpring MVC）：
-
役割：コアとなるバックエンドロジック。
-
機能：JSON/HTTPS APIを公開します。認証、ビジネスロジック、外部システム（データベース、メインフレーム、メール）との通信を処理します。
-
-
データベース（Oracleデータベーススキーマ）：
-
役割：データの永続化。
-
機能：ユーザー登録情報、ハッシュ化された資格情報、アクセスログを格納します。注記：コアバンキングデータはメインフレームに保持されます。
-
重要な関係：Webアプリ（SPA経由）とモバイルアプリの両方が、APIアプリケーションと通信します。その後、APIアプリケーションはローカルデータに対してデータベースに接続し、コアバンキングデータに対してはメインフレームに接続します。
4. レベル3：コンポーネント図
目的：特定のコンテナ（APIアプリケーション）にズームインし、その内部構成要素を示す。
参照図：画像3。
分析
この図は、APIアプリケーションコンテナを論理的なコンポーネントに分解しています。
-
コントローラー（Spring MVC Restコントローラー）：これらは受信するHTTPリクエストを処理します。
-
ログインコントローラー：ユーザー認証を処理します。
-
パスワードリセットコントローラー：パスワード回復のフローを処理します。
-
アカウント概要コントローラー：ユーザーのアカウントデータを取得します。
-
-
コンポーネント（Spring Bean）：これらはビジネスロジックを含んでいます。
-
セキュリティコンポーネント：ログインとパスワード変更を処理します。ログインコントローラーおよびパスワードリセットコントローラーで使用されます。
-
メールコンポーネント：メールの送信を処理します。パスワードリセットコントローラーで使用されます。
-
メインフレーム銀行システムファサード：外部メインフレームシステムのラッパーです。内部API呼び出しをレガシーなメインフレームが要求するXML/HTTPS形式に変換します。アカウント概要コントローラーで使用されます。
-
重要な関係： アカウント概要コントローラー は メインフレーム銀行システムファサード外部メインフレームからデータを取得するために使用し、APIレイヤーと統合レイヤーの間の責任の分離を示しています。
5. レベル4：デプロイメント図
目的：ソフトウェアコンテナが物理インフラにどのようにマッピングされるかを示すことです。
参照図：画像5。
分析
この図は実行環境を示しています。
-
顧客側：
-
モバイルデバイス：モバイルアプリ（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では、「Big Bank plc」の境界が、内部システムと外部のエイジェントを明確に区別しています。
-
レベル2では、「インターネットバンキングシステム」の境界が、構築中の特定のソフトウェアをカプセル化し、レガシーメインフレームから分離しています。
-
-
関心の分離：
-
フロントエンド vs. バックエンド：シングルページアプリケーション（フロントエンド）とAPIアプリケーション（バックエンド）の分離により、独立した開発とスケーリングが可能になります。
-
データの分離：機密性の高いコアバンキングデータはメインフレームに保管され、インターネットバンキングシステムは自身のOracleデータベースに必要なユーザーアクセスデータのみをキャッシュします。
-
-
技術非依存性（適切な場合）：図は、アーキテクチャの意思決定に関連する場合にのみ技術（Java、Angular、Oracle）を指定していますが、主にブロック間の 関係性および 責任ブロックの責任を重視しています。
-
表記法：標準的なC4表記が使用されています：
-
人物：棒人形（この特定のレンダリングスタイルでは円）。
-
ソフトウェアシステム／コンテナ／コンポーネント：色の異なる丸角長方形（内部／主要なものは青、外部／二次的なものは灰色）。
-
関係：プロトコルを説明するラベル付きの破線矢印（例：[HTTPS]、[JSON]、[JDBC]）。
-