お客様のニーズに合わせたパーソナライズされたFinMV見積もりについては、お問い合わせください。
あなたの会社のテクニカルディレクターは、金融プラットフォームの立ち上げを計画するときに、プロジェクトアーキテクチャオプションを選択する必要があります。彼が利用できるアーキテクチャオプションと、どれを選択するのが良いですか？
モノリシックアーキテクチャは雪だるまに例えられます。プロジェクトを始めたばかりの頃、雪玉はまだ小さく、少人数のチームでも育てて転がしていくことができます。数年が経つと、その雪玉はすでに20人の開発者が押すほど大きくなっています。さらに数年経つと、大量のプログラムコードを抱えた雪玉を数百人の開発者が転がすことになりますが、新機能のリリースはすっかり遅くなってしまいます。
その結果、経営陣はCTOやチームメンバーを交代させ始めますが、状況は悪化するばかりです。新しいチームメンバーは、なぜ雪玉がこのような形になったのか、その経緯を知りません。製品ドキュメントもすぐに古くなってしまいます。
それなら、最初から正しく作ればいいのではと思うかもしれません。しかし第一に、ビジネスの初期段階では常にリソースが限られており、開発者も専門知識も時間も不足しています。経営陣は急かし、プログラマーはできるだけ速く仕上げようとします。
第二に、技術者はこう考えます。「今はモノリシックアーキテクチャでいいだろう。ビジネスが成長したら、その時に全部作り直せばいい」。しかし残念ながら、実際に稼働中のモノリシックプロジェクトをマイクロサービスアーキテクチャへ移行するのは、最初から書き直すよりも何十倍も難しいことが判明します。
私たちは、あなたの金融プラットフォームを最初からマイクロサービスアーキテクチャで構築します。
マイクロサービスアーキテクチャは、歩道の敷石に例えられます。プロジェクトが成長するにつれて、歩道には新しい敷石が次々と追加されていきます。あるコンポーネントが古くなった場合は、その敷石を新しいものに交換するだけで済みます。
このアーキテクチャには多くの利点がありますが、最も重要なものを挙げると次のとおりです。
最初の事例。多数のユーザーを抱えるP2Pレンディングプラットフォームの経営陣は、異なる通貨を使う国々の市場に進出することを決定しました。このプラットフォームはモノリシックアーキテクチャで、組み込まれていた通貨はユーロひとつだけでした。スウェーデン（スウェーデンクローナ）、ポーランド（ポーランドズウォティ）、チェコ（チェココルナ）の市場に進出するには、複数通貨対応を導入する必要がありました。
このような機能の実装にはチーム全体で数か月を要し、新機能の開発はさらに遅れました。マイクロサービスアーキテクチャであれば、すべてがはるかに簡単かつ迅速だったでしょう。
2番目の事例。当初、サイトビルダーは自国語のみでリリースされ、経営陣は他の市場への進出を計画していませんでした。プロジェクトはモノリシックアーキテクチャで、機能は急速に拡大していきました。プラットフォームの構造は、あらゆるものが互いに絡み合った複雑な網のようなものでした。ある日、事業側はプラットフォームを他言語版でリリースすることを決定しました。当初は、言語ファイルを追加するだけでインターフェース全体が翻訳されると思われていました。
しかし実際には、プロジェクト全体を作り直す必要がありました。例えば、データベース内の会社名や商品名は、これまでは1つの言語だけで保存されていましたが、今後はすべての言語で保存する必要がありました。ビジネスロジック上、情報を重複させることはできず、すべての言語の名称を同時に保存しなければなりませんでした。それに伴い、マイページやバックオフィスのインターフェースにも変更が必要になりました。インターフェースの変更により、受信データの検証ルール、言語ごとに異なる語尾の原則によるメールテンプレート、テストなどの変更も必要になりました。
すべてがすべてに絡み合っていたため、新しい言語のリリースと合わせてマイクロサービスアーキテクチャへの移行が決定されました。モノリシックアーキテクチャからマイクロサービスアーキテクチャへの移行プロセスには1年以上かかりました。
3番目の事例。あるフィンテックプラットフォームは、古いバージョンのPHPとLaravelで構築されていました。より新しいバージョンへの移行、およびデータベースをMariaDBからPostgreSQLへ変更することは事実上不可能でした。なぜなら、チーム全体が移行作業だけに数か月を費やす必要があったからです。
当時、新しいバージョンのPHPとLaravelはプロジェクトの動作とその後の開発を加速させることができたはずですが、モノリシックアーキテクチャが技術スタックの更新を妨げていました
。
