コンポーザブル・バンキングのコアとなるドメイン駆動デザイン

銀行業界は、常に変化する環境下で事業を展開している典型的な例です。顧客の期待や市場の動向が急速に変化し、デジタル・ネイティブ企業をはじめとする新たな競合が次々と現れ、規制は常に変化し、ますます厳しくなっています。これらは、組織の俊敏性を新たなレベルへと引き上げることを求めています。

構成可能性は、このような市場の変化に直面する銀行が、より俊敏かつ効率的になるためのアーキテクチャ原則です。ガートナーによると、構成可能アーキテクチャの重要な側面は、「適切に定義されたパッケージ化されたビジネス機能のまとまりのあるセットであり、俊敏性を最大化するのに十分な小ささでありながら、整合性を維持するのに十分な大きさの、独立した構成要素の組み合わせを表す」と定義されます。

Domain-Driven Design - 堅牢性と適応性を保証

Domain-Driven Design（DDD）は、Eric Evansが2003年に提唱し、その後改善・拡張された、ドメインのよく練られたモデルに基づいてソフトウェア・システムを構築する必要があるという考え方です。DDDは、トランザクション・バンキングのような複雑なドメインに最も有効です。DDDフレームワークは、ビジネス・ドメインとサブドメインに合わせた機能コンテキストによって範囲を限定された、明確に定義された独立したソリューション・コンポーネントの作成を可能にし、複雑さを軽減します。

Evansは、各コンポーネントが、エンド・ユーザーに提供できる、または他のコンポーネントにサービスを提供できる、他のコンポーネントへの依存性を最小限に抑えつつ、特定の機能を提供すると主張しています。したがって、DDDは、構成可能なアーキテクチャの重要な要件である、アジャイルな構成可能性を推進する主要な構成要素となる、明確に定義されたパッケージ化されたビジネス機能またはソリューションの開発を可能にします。

たとえば、トランザクション・バンキングのような複雑なドメインは、流動性管理、資金管理、決済などのドメインに分解されます。資金管理は、回収管理やキャッシュフロー予測といったサブドメインにさらに細分化されます。独立したソリューションおよびサービス・コンポーネントは、特定されたドメインおよびサブドメインに沿って構築され、これらは機能コンテキストによって範囲が限定されます。構成要素となるソリューションおよびサービス・コンポーネントは、ビジネスの俊敏性を最大限に高めるのに十分な小ささでありながら、運用の整合性を確保するのに十分な大きさとなるように最適化されています。

ドメインドリブンの構成可能な銀行業務—俊敏性と効率性の最適化

Oracle Bankingスイートは、DDDを活用し、リテール・バンキングおよびコーポレート・バンキング全般にわたる、独立したコンポーザブル・ソリューションの構成要素を豊富に提供する、包括的な最新のバンキング・ソリューション・スイートです。各ビルディング・ブロックと基盤となるマイクロサービスは、ドメイン・モデリングを使用して構築されており、これにより、ドメインまたはサブドメインの境界コンテキストを中心とした論理コンポーネントまたは構成要素の最適なコンポーザブル・スイートが可能になります。（下の図を参照）

リテール・バンキング向けには、このスイートは、顧客の獲得、サービスデリバリー、延滞管理といった個々のビジネス機能にわたるビルディング・ブロックを提供します。コーポレート・バンキングの場合、銀行は、法人口座、法人融資、資金管理、流動性管理、貿易金融、サプライチェーン・ファイナンス、財務管理など、さまざまなビジネス・ラインで構成可能なブロックを活用できます。

すぐに使えるコンポーネントのメニューに加え、このスイートにはマイクロサービスの豊富なライブラリも含まれています。これらのマイクロサービスは、コア・サービスと共有サービスの重複に伴うリスクとコストを軽減し、管理と制御を容易にし、追加コンポーネントの展開を加速します。シェアード・サービスの例としては、通貨管理、手数料計算、データ管理、トランザクション・コード管理などがあり、これらすべてを銀行は集中型かつ独立したサービスとして容易に管理できます。これにより、制御が最適化され、労力の重複が減少し、より迅速で効率的なイノベーションが可能になります。

このスイートには、マイクロサービスの迅速な開発、導入、管理を可能にする広範な技術マイクロサービス・シャーシも含まれています。このシャーシは、コードの重複を排除し、使い捨てで、並行して、構成可能なステートレス・マイクロサービスでサービス管理を最適化します。スイートの共有機能マイクロサービスと技術的なマイクロサービスは、サービスの最適な共有と再利用性の最大化により、運用コストを削減しつつ、堅牢な構成可能性を強化します。また、追加コンポーネントの迅速な導入を促進し、市場投入までの時間（TTM）をさらに短縮します。

さらに、このスイートは、ビルディング・ブロックがそのすべての機能をAPI経由で公開するAPIファーストのアプローチを採用しています。スイート製品の独立したメッセージ・ルーティングとルール・エンジンは、システムの簡単かつ迅速な統合を可能にし、ビジネス・ドメインやその他のサービス向けの次世代コンポーザビリティ機能を実現します。

無限の可能性

Oracle Bankingスイートを利用すれば、銀行は多様なニーズに合わせて変革の道筋を自由に調整できます。可能性は無限大であり、いくつかの強力なユースケースをご紹介できることを嬉しく思います。

• リテール・バンキング・ビジネスを迅速に立ち上げたいチャレンジャー・バンクは、フロントオフィスからバックオフィスまで、そして顧客獲得からサービスデリバリまで、事前統合された複数のリテール・バンキングの構成要素コンポーネントを選択し、エンドツーエンドのデジタル・リテール・バンキングを構築して展開できます。
• Banking-as-a-Service（BaaS）の検討を考えている小規模の銀行は、口座および預金商品を構築・展開できるコンポーネントを選択し、顧客獲得とサービスデリバリーを管理するサードパーティ・チャネルと迅速に統合でき当院ます。
• トランザクション・バンキング分野でのサービス拡充を目指す中規模の銀行は、仮想の口座管理のような単一コンポーネントから始めることができます。ビジネスが拡大するにつれて、銀行はスイートの共有機能および技術基盤サービスを活用して、資金管理や流動性管理などの他のトランザクション・バンキング・コンポーネントを効率的に構築および展開できます。
• 変革を段階的に進めたい中規模銀行は、まずデジタル・オムニチャネル機能を展開するために単一のコンポーネントを選択できます。その後、支援されたエンゲージメントと処理、および製品管理とコア・オペレーションを変革するために、コンポーネントを簡単に構成および追加できます。
• 法人口座向けにクラス最高のコアを求める大手ティア1銀行は、高い拡張性のために構築されたコーポレート・バンキング口座コア・エンジンを導入し、そのコンポーネントを既存のシステムや外部エコシステムと迅速に統合できます。

Oracle Bankingスイートは、エコシステム・アプローチやエンドツーエンドの事前統合スイートなど、特定のパスに変革を強制することはありません。その最先端の構成可能性により、銀行は任意のアプローチを選択したり、複数のアプローチを組み合わせたり、さらには異なるビジネス・ラインの要件に合わせて調整したりできます。

スイートのドメインドリブンの構成可能性により、銀行はあらゆるカスタマー・ジャーニー、ユーザー・エクスペリエンス、またはビジネスおよび製品ライン機能を迅速かつ効率的に構築できます。カスタマー・ジャーニーやユーザー・エクスペリエンスを容易に再考・再定義し、革新的な製品やサービスを迅速に構築・提供できます。銀行はまた、新しい流通およびサービス・モデルを容易に採用し、パートナーとの連携を強化して、製品と収益源を共同で革新する力を持ちます。

真にアジャイルで効率的なドメインドリブンの構成可能性により、銀行は自信を持って新しい機能、変革の道筋、ビジネス・モデルを導入し、常に進化しダイナミックな業界で成功を収める準備を整えることができます。