Moneythor では、ソフトウェアの寿命と拡張性を確保するために、保守が容易でコスト効率が高く、業界標準に完全に準拠したコンポーネントを使用して実装できる技術ソリューションを提供することに注力しています。
ソフトウェア業界は、新しいアーキテクチャが実装され、ツールがすぐに廃止されるなど、急速な発展の影響を受けやすく、今後もその傾向は続くでしょう。また、ソリューションの主要な差別化要因を確立するための新しい取り組みが開発されるため、競争も激しくなります。クラウド プロバイダーがソフトウェア、ハードウェア、インフラストラクチャに多額の投資を行っている今日では、この傾向はさらに強まっています。
絶えず変化する環境の中で、技術アーキテクチャの選択を慎重に行う際に何を考慮し、構築する際に何に注意を払っているかを確認しましょう。 マネーソーソリューション.
技術的負債とは何ですか?
技術的負債にはいくつかの解釈がありますが、最も一般的に受け入れられている定義は次のとおりです。 後の段階でリファクタリングや再検討が必要になることを承知の上で、急速な利益を得る目的で下されたあらゆる決定私たちの場合、これは、たとえば、製品の長期戦略に沿っていない完全に機能するコードを実装することや、その時点で必要な機能要件がないため自発的に残されたエッジケースである可能性があります。
なぜこれが私たちにとって重要なのでしょうか?
大半のエンタープライズソフトウェアソリューションと同様に、Moneythorプラットフォームは、かなりの数のオープンソースライブラリ上に構築されています。オープンソースソフトウェアは、歴史的に個人によって開発されるか、業界リーダーによって資金提供されてきました。今日では、大規模な組織が、自社のニーズを満たすために、多くのオープンソースソフトウェアプロジェクトの開発に貢献するケースが増えています。今や避けられないことを考えてみましょう。 アパッチカフカ （LinkedInより） クベネフィット （Googleより） 反応する (Facebook/Meta より) リストは毎日長くなっています。
Moneythor ソリューションの複雑さを考えると、ソリューションのあらゆる側面を自分たちで構築することは想像もできないほど、非常に時間と費用がかかります。また、有名な組織が後援し、複数の本番環境で集中的にテストされたこれらのサードパーティ プロジェクトと同じレベルの品質に到達できないまま、車輪の再発明をするリスクがあることは言うまでもありません。
そうは言っても、セキュリティは大きな懸念事項です。サービスがデータ侵害を受けたという話は誰も聞きたくないものですが、定期的に報告されているような脆弱性を回避することはほぼ不可能です。 一般的な脆弱性と露出 そして、多くの場合、それらを修正するために即時の行動が必要になります。
そのため、当社はすべてのサードパーティ ライブラリを慎重にテストして選択し、代替案や、ソース コードを理解してセキュリティ問題を自力で修正することの難しさを常に考慮しています。その後、必要なレイヤーを使用してソリューションに統合し、簡単にアップグレードしたり置き換えたりできるようにします。
技術的負債に注意する
ソース コードの書き換えや、あるテクノロジから別のテクノロジへの切り替えには、多くの場合、高額なコストがかかり、関係者に正当化するのが困難です。そのため、私たちは最初から技術的負債を考慮に入れています。ソリューションの設計方法はここで重要な役割を果たしており、場合によっては、未確認の機能の追加部分に対応するソリューションを準備するために、最初の追加労力を費やすことをためらいません。
これは、新しい機能や項目の最終的な実装とみなされるものを最初から記録する機会でもあります。その際、時間どおりに実用的なソリューションを作成するためにいくつかの近道をとらざるを得ませんでしたが、一部の部分は後で再検討できることはわかっています。
機能要件が進化し、既存のコードを見直す必要があることに注意する必要があります。その場合、技術的負債項目に対処しているわけではありません。これは、継続的に強化されるソリューションの自然なライフサイクルにすぎません。
技術的負債を管理する
そうは言っても、未来を予測することは不可能であり、今後登場するソリューションや流行語に賭けるのは危険です。たとえば、Moneythor ソリューションは、過去数十年間に何百万もの実績のあるエンタープライズ ソフトウェア プロジェクトの開発をサポートしてきた、非常に成熟した信頼できるプラットフォームである Java Enterprise アプリケーション スイートの基盤を活用しています。Java プラットフォームの機能の 1 つは、由緒あるブロッキング サーブレット API です。これは、新しいリアクティブ プログラミング イニシアチブによって推進されている非同期の非ブロッキング ストリーム処理アプローチとは異なる、実績のあるモデルです。
コミュニティと多くの依存関係がこの新しいプログラミング パラダイムを採用した後、将来的に後者がデフォルトのアプローチになった場合、以前と同じレベルの機能を備えたソリューションを新しい標準にするために時間を投資する必要が生じるという技術的負債が生じる可能性があります。
この場合も、エンジニアリング チームの役割は、既存のビジネス ロジックの調整に時間を費やすことなく、既存の機能を書き直して調整する労力を最小限に抑えられるようにソリューションを設計することです。
データストレージシステムは技術的負債を簡単に生み出す
よく知られているように、世界は毎年、指数関数的にデータを生み出し、消費しています。膨大な量のデータの処理と分析は、金融サービス業界を含むさまざまな分野の組織にとって常に大きな課題となっています。ソフトウェア業界が、進化し続けるデータの課題を解決するために、常に新しいツールの開発に取り組んで構築していることは驚くことではありません。
リレーショナル データベースは過去にはデフォルトで、クラウド管理バージョンは非常にスケーラブルでしたが、現在ではデータの保存とクエリの方法にはまったく異なるアプローチがあります。従来のリレーショナル データベースからドキュメント ストアなどに切り替えることは、2 つの異なるリレーショナル データベース ベンダーを切り替えるほど簡単ではありません。多くの場合、既存のソリューションは、新しいデータ ストアには存在しない原則と契約に依存しています。
技術的負債は結果をもたらす
過去数十年にわたるこの業界での経験と複数の異種プロジェクトから、技術的負債がブラックホールになるしきい値があり、このしきい値は時間の経過とともに、特に何も対策を講じない場合にはどんどん低くなることがわかりました。
つまり、限界に達すると、技術的負債を解消することが不可能になる可能性があり、最終的にはすべてを最初から書き直す方がコストが安くなりますが、これは非常に大きな労力であり、士気を低下させる可能性があります。そうなると、1 つのテクノロジーで得た経験と知識をすべて再構築する必要があります。
たとえば、人気の PostgreSQL リレーショナル データベースから、同じく人気の Mongo DB ドキュメント ストアに切り替えることは、ソフトウェアを 2 つの永続レイヤーと互換性を持たせるだけではありません。データの流れ、トランザクション プロセス、両方のソリューションの長所と短所、得られるものと失うものへの影響を理解することも重要です。これを見落とすと、遅延や余分なコスト、場合によっては障害につながる可能性があります。
技術的負債を管理するための当社のアプローチ
前述のように、開発を予測することは不可能であり、すべてを一度に実装することも合理的ではありません。私たちにできることは、不必要な障害から身を守ることです。よく知られた実績のあるアーキテクチャとデザイン パターンは、まさにこの目的のために存在します。
まず、このソリューションは スプリングフレームワークここで注目すべき最も重要な点は、Springを選んだのは、Springが非常に人気があり、メンテナンスが行き届いており、エンタープライズグレードのソフトウェアソリューションの多くの側面に対処するのに役立つ豊富なサブプロジェクトを提供しているからだけではなく、Springの核心は、コードを分離し、実装を大幅に容易にする依存性注入フレームワークであるということです。 関心事の分離 原理。
可能な限り、サードパーティのライブラリから独自のコードまですべてを分離して、実装を簡単に置き換えられるようにしています。次に、新しい機能を実装することを決定したら、ビジネス ロジックの具体的な実装をフレームワークから分離することから始めます。また、Spring またはサードパーティのライブラリで動作する技術フレームワークとビジネス要件の実装の間にある汎用の中間層を設計するために余分な時間を費やします。この中間層の目的は、機能の抽象化を提供することです。これにより、後で簡単にカスタマイズでき、基盤となる技術コンポーネントのアップグレードや置き換えの影響から保護できます。
その結果、Moneythor ソリューションは、機能ロジックの具体的な実装だけでなく、その実装を備えたフレームワークそのものになります。これにより、非常に高いレベルの柔軟性が得られ、これは私たちにとって非常に貴重です。また、すべてのクライアントに対して同じ製品を維持することもできます。もちろん、さまざまな地域、ターゲット環境、クライアント固有の機能に合わせてソリューションを調整しますが、これはゼロフォークのソースコードのバージョンが 1 つだけであるおかげで実現されています。
現在、このアプローチのメリットを測定できます。このアプリケーション スイートの開発を開始したのはほぼ 10 年前ですが、脆弱なライブラリは引き継いでいません。代わりに、最新バージョンの Spring とその他のサードパーティ コンポーネントを使用することで、予算内で新しいテクノロジのサポートを追加でき、ソフトウェアの大部分をリファクタリングする必要もありません。最後に、これにより、開発チームは最新のテクノロジとツールを備えた最新のアーキテクチャに取り組む意欲を維持できます。
本質的には、複雑な設計とエンジニアリングと許容できるやり直しコストの間の適切なバランスを見つけることが重要なのですが、Moneythor ソリューションによってそのバランスを実現できており、今後もそれを継続していきます。
